Closed Bug 99356 Opened 23 years ago Closed 23 years ago

Mozilla 0.94 AND 0.95 on OSX 10.X form upload bug!

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: matiasnu, Assigned: rods)

References

(
URL
)

Details

Attachments

(12 files)

Testing upload... a 170k JPEG did not work correctly
(deleted), image/gif
Details
A 24k JPEG... will it work?
(deleted), image/jpeg
Details
Now running Moz 0.94 in MacOS 9.1 -> Large JPEG try 1
(deleted), image/jpeg
Details
OS 9.1 try 2
(deleted), image/jpeg
Details
Try 3
(deleted), image/jpeg
Details
Netscape 6.2 Carbon OS X upload test 1
(deleted), image/jpeg
Details
NS 6.2 OSX Test 2
(deleted), image/jpeg
Details
Build 2001111506 MacOSX.04 upload 'Try3' JPEG file
(deleted), image/jpeg
Details
Build 2001111506 OSX.04 upload BIG pdf
(deleted), application/pdf
Details
MacOSX 10.0.4 Moz 0.9.6 build 2001112020 attempt 116kB file upload
(deleted), image/jpeg
Details
MacOSX 10.0.4 Mozilla 0.9.6 build 2001112020 216kB file upload
(deleted), image/jpeg
Details
test
(deleted), image/jpeg
Details
T he page recieving the file returns this code: <html><head><title>June Comet | Saving...</title><script src="javascript / common.js"></script></head><body onload="window.open('&Closeme= ' + window.top.name + '&Method=AddImage&SectionTypeI d=& ImageFormatId=&ImageFormatTitle=&Position=&ImagePositionTit le=& SectionNo=&ImageId=','');"></body></h t ml> I tried uploading a 4k gif named gellerasen.gif, it worket fine. When I tr y to upload a 32k jpeg named MINI-Z.jpg it says page cannot be found. When I try uploading a 552k Photoshop file the browser crashes on me... every time! Here's the crash log: Date/Time: 2001-09-12 17:42:37 +0200 PID: 762 Command: Mozilla Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_PROTECTION_FAILURE (0x0002) at 0x00000000 Thread 0: #0 0x00144ce8 in 0x144ce8 () #1 0x04623f08 in 0x4623f08 () #2 0x0012daf4 in 0x12daf4 () #3 0x0193eaec in 0x193eaec () #4 0x0193f9c4 in 0x193f9c4 () #5 0x0193d9b8 in 0x193d9b8 () #6 0x024e08fc in 0x24e08fc () #7 0x024e1098 in 0x24e1098 () #8 0x024ddec8 in 0x24ddec8 () #9 0x01afa628 in 0x1afa628 () #10 0x01afa0c4 in 0x1afa0c4 () #11 0x0015cf34 in _XPTC_InvokeByIndex () #12 0x0015ce54 in _XPTC_InvokeByIndex () #13 0x016ae9bc in 0x16ae9bc () #14 0x016b3644 in 0x16b3644 () #15 0x015f5a98 in 0x15f5a98 () #16 0x015fd9a4 in 0x15fd9a4 () #17 0x015f5f64 in 0x15f5f64 () #18 0x015dc638 in 0x15dc638 () #19 0x01ee6f90 in 0x1ee6f90 () #20 0x028c1d9c in 0x28c1d9c () #21 0x028c3520 in 0x28c3520 () #22 0x0193208c in 0x193208c () #23 0x01933db4 in 0x1933db4 () #24 0x01933be0 in 0x1933be0 () #25 0x01e2cb94 in 0x1e2cb94 () #26 0x01e2be8c in 0x1e2be8c () #27 0x01e2adfc in 0x1e2adfc () #28 0x01e36210 in 0x1e36210 () #29 0x01e358c8 in 0x1e358c8 () #30 0x01e35858 in 0x1e35858 () #31 0x00180858 in 0x180858 () #32 0x00180744 in 0x180744 () #33 0x001420e0 in 0x1420e0 () #34 0x0014218c in 0x14218c () #35 0x0014218c in 0x14218c () #36 0x0014218c in 0x14218c () #37 0x0014218c in 0x14218c () #38 0x0195f784 in 0x195f784 () #39 0x0195f614 in 0x195f614 () #40 0x0197d8f0 in 0x197d8f0 () #41 0x0196e328 in 0x196e328 () #42 0x0196dd7c in 0x196dd7c () #43 0x0196d8b4 in 0x196d8b4 () #44 0x01750124 in 0x1750124 () #45 0x000910a4 in 0x910a4 () #46 0x00091a9c in 0x91a9c () Thread 1: #0 0x7000424c in _syscall () #1 0x706584b8 in _ProcessReadyEvent () #2 0x706582b0 in _CarbonSelectThreadFunc () #3 0x70014f04 in __pthread_body () Thread 2: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x70653be0 in _BSD_pthread_cond_wait () #5 0x70653bc0 in _CarbonConditionWait () #6 0x7065557c in _CarbonOperationThreadFunc () #7 0x70014f04 in __pthread_body () Thread 3: #0 0x70059b48 in _semaphore_timedwait_signal_trap () #1 0x7003f7f8 in _semaphore_timedwait_signal () #2 0x70015f68 in __pthread_cond_wait () #3 0x7003f7c4 in _pthread_cond_timedwait_relative_np () #4 0x7029b590 in _TSWaitOnConditionTimedRelative () #5 0x7029cdac in _TSWaitOnSemaphoreCommon () #6 0x702e5f98 in _TSWaitOnSemaphoreRelative () #7 0x702e7208 in _TimerThread () #8 0x70014f04 in __pthread_body () Thread 4: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x7029b550 in _TSWaitOnCondition () #5 0x7029cd94 in _TSWaitOnSemaphoreCommon () #6 0x7029cce4 in _TSWaitOnSemaphore () #7 0x7029cba8 in _AsyncFileThread () #8 0x70014f04 in __pthread_body () Thread 5: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x70653be0 in _BSD_pthread_cond_wait () #5 0x70653bc0 in _CarbonConditionWait () #6 0x70653ab4 in _CarbonInetOperThreadFunc () #7 0x70014f04 in __pthread_body () Thread 6: #0 0x700007b8 in _mach_msg_overwrite_trap () #1 0x700056e4 in _mach_msg_overwrite () #2 0x700277b0 in _thread_suspend () #3 0x70027744 in __pthread_become_available () #4 0x70027468 in _pthread_exit () #5 0x70014f08 in __pthread_body () Thread 7: #0 0x70059b68 in _semaphore_wait_signal_trap () #1 0x70016110 in _semaphore_wait_signal () #2 0x70015f78 in __pthread_cond_wait () #3 0x70015d18 in _pthread_cond_wait () #4 0x7029b550 in _TSWaitOnCondition () #5 0x7029b59c in _TSWaitOnConditionTimedRelative () #6 0x7029b6a4 in _MPWaitOnQueue () #7 0x708de050 in _SyncTaskProc__13TNodeSyncTaskPv () #8 0x70291434 in _PrivateMPEntryPoint () #9 0x70014f04 in __pthread_body () PPC Thread State: srr0: 0x00144ce8 srr1: 0x0000d030 vrsave: 0x00000000 xer: 0x00000020 lr: 0x0012e0a0 ctr: 0x0012e084 mq: 0x00000000 r0: 0x0012daf4 r1: 0xbfffc59c r2: 0x0025d000 r3: 0x00000000 r4: 0xbfffc6c0 r5: 0x04d790c0 r6: 0x00000000 r7: 0x00000000 r8: 0x00000000 r9: 0x00000001 r10: 0x00000001 r11: 0x6a57eae0 r12: 0x00256138 r13: 0x002625bc r14: 0x00000002 r15: 0x0000002b r16: 0x0025b568 r17: 0x00000000 r18: 0x00000005 r19: 0x04f6a3c8 r20: 0x0325cb30 r21: 0x04761b30 r22: 0xbfffc6c8 r23: 0x01738e70 r24: 0x04d790c0 r25: 0xbfffc6cc r26: 0x0173ae60 r27: 0xbfffc6b8 r28: 0x04d790c0 r29: 0x0026b12c r30: 0x0026b6d8 r31: 0x00000000 **********
Reporter, please also test with a recent nightly build, and test on other operating systems as well, especially since nobody else can access your testcase URL.
Reporter, does this still happen using 0.9.4?
0.94 solves the problems. 0.93 crashed since the response from the server was; --------------------------------------------- Microsoft VBScript runtime error '800a0005' Invalid procedure call or argument: 'MidB' /Comet/system/fileupload.asp, line 80 --------------------------------------------- Although I still cannot upload a document properly since now, instead of crashing, I get the error message above. The upload routine is written inhouse, but works on Explorer on different platforms, so either we have an error in the uplaod routine on our server OR you have some kind of error in your upload routines. (maybe Mozilla isn't sending the form upload info, the same way or with the same additional parameters as Explorer) I think it may be our fault, so I will look into it.
Severity: critical → normal
That's fine, Matias. I'm going to mark this bug WFM for the time being since the crash no longer occurs. If you're able to determine that Mozilla is still at fault here, then don't hesitate to reopen this or open a new bug.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Hi again, It seems that the Mac OS X version of Mozilla 0.94 (and earlier) has some difference to Windows or MacOS 9.X versions when uploading files with form upload procedures. I tried uploading several files with Windows AND Mac OS 9 versions of Mozilla 0.94 and they uploaded fine. The OS X version, however, seems to send the form differently since it causes the recieving server to return an error. I cant say exactly WHAT is different with the OSX version,since I don't have any deep knowledge about how mozilla handles forms etc. but SOMETHING seems to be wrong. Maybe you can track down the error by comparing what mozilla sends to the server on different platforms?
Severity: normal → critical
Status: RESOLVED → UNCONFIRMED
Component: Browser-General → Form Submission
Resolution: WORKSFORME → ---
Summary: Mozilla 0.93 on OSX 10.04 crashes when uploading a file → Mozilla 0.94 on OSX 10.04 form upload bug?
The problem seems to have to do with larger files being submitted > 100k? I'll try to find out exatly what the limit is.
->reassign to form submission.
Assignee: asa → rods
QA Contact: doronr → vladimire
Matias, can you reproduce this problem using another form? For example, try uploading a file greater than 100 KB in size as an attachment to this bug. If it works fine, it's probably a somewhat different problem specifically related to the intranet page you're using.
Simon, is this the problem you've been working on?
It may be related to bug 100353, but there were no crashes involved there. Can someone set up a test site where we can test uploads, please?
Attached image A 24k JPEG... will it work? (deleted) —
OK Greg, I successfully uploaded a small gif and a small JPEG, to this bug. But when I tried several different large (>100k) JPEGS, bugzilla told me to enter a description to the attachment although I HAD entered a description. Seems to be the same problem but with a different server response form my Intranet system. I will now try the same uploads with Mozilla on OS9.1.
Attached image OS 9.1 try 2 (deleted) —
Attached image Try 3 (deleted) —
Well folks, I think this says it all. There definetly is >something< wrong with Moz on OS X 10.0.4. I'll be upgrading to OS X 10.1 in a few days... after the upgrade I will try again, in case it is the OS' fault. Simon, the crashes you're talking about ended with 0.94.
Blocks: 102998
Upgrading to 10.1 did NOT solve the problem. (not that I thought it would, but one never knows these days)
Reporter, if you're only experiencing the crashes when uploading to your intranet page, then we're going to need more information about that page and what it does.
Greg, the crashing has nothing to do with this bug anymore, it's the form upload on Moz 0.94 OSX which is flawed in some way. As you can see above I couldn't upload large files to BUGZILLA(and our intranet system) with OSX but Moz on OS 9 worked great (as well as Moz on Wintel).
Just wanted you to know that 0.95 did NOT solve this bug. I still cannot upload large (>100k) files to bugzilla OR our intranet system.
Summary: Mozilla 0.94 on OSX 10.04 form upload bug? → Mozilla 0.95 on OSX 10.1 form upload bug!
I was hoping that the fix for bug 100353 would have fixed this, and that should be in the 0.9.5 branch. Just to be sure, can you test an 0.9.4 build, and a trunk build?
sfraser, Sorry, I changed the summary from 0.94 to 0.95. I noticed the bug in 0.93 (as you probably can see if you look at the history), it was there in 0.94, and it's still in 0.95. Note that this only occurs on MacOSX 10.X. MacOS 9.X and Windows builds does not have this problem. What's the difference of the Moz0.95 "ordinary" build vs a trunk build?
Summary: Mozilla 0.95 on OSX 10.1 form upload bug! → Mozilla 0.94 AND 0.95 on OSX 10.X form upload bug!
I have experienced, on many occasions, a similar thing. While uploading a 252k pdf file, the browser dose not crash, but it will not take the file. I can leave it for 20 minutes --spinning cursor. OSX.04 Moz 0.9.5 Build ID: 2001101516
Attached image Netscape 6.2 Carbon OS X upload test 1 (deleted) —
Attached image NS 6.2 OSX Test 2 (deleted) —
Now, everybody, please take a deep breath and explain to me why Netscape 6.2 (Carbon) on OSX which is based (to my knowledge) on Moz 0.94, uploads large files GREAT? I tried on our intranet system AND on bugzilla (as you can see), and it just works. I'll leave the bug open since Moz 0.94 and 0.95 still has the upload bug. This is really strange!
Another testing of the upload via a form. Build 2001111506 MacOSX.04 Test: upload 'Try3' JPEG file as an attachment to this bug.
Test of uploading BIG files via a form. Build 2001111506 MacOSX.04 Test: Upload a max size attachment to this Bug. (The previous test attachment:58450 was successful, because you can see it;)
WFM BuildID: 2001111506 MacOSX.04 I uploaded a 290k and a 900k attachment to this bug successfully. But I find your descriptions of 'large' files quite humorous. I work in the HQprint industry, where an average image file can be 34mb. And yes, some of my vendors want us to post these LARGE files onto their 'forms' to submit them across the internet. (Because they think JoePublic can't handle FTP) I'll re-test this at work with some real LARGE files.
Summary: Uploading files via an html form, errors increase with size. Test Case: 1) Surf to a form that allows you to attach/post a file. 2) Attempt to Post a file of sufficient size. 3) Get an Error. The bugzilla page you are reading now is an example of a 'form that allows attaching/posting of files'. You can test post a file as an attachment. This bug seems to have been squashed. First on the MacClassicOS(8-9) and finally on OSX. -------------------------------------------------------------------- Does anybody still experience this bug with recent builds?
Uploading this one with autodetect content type. If it works will mark the bug as WFM on 0.9.6.
This now appears to work on MacOS X on Moz 0.9.6 for the same attachements which were noted as working on MacOS 9 but failing on the MacOS X build. Marking as fixed as Nagano indicates the large files work too. Apologies for the spam in uploading more attachments.
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Attached image test (deleted) —
verifying on 2002-01-28-08-trunk OS X
Status: RESOLVED → VERIFIED
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: