Last modified: 2012-08-14 17:36:01 UTC
It may be broken on FF 3.6 period, but this is the first report & the first way I could confirm the issue. One can select multiple files, but all files except the first one fail with a "the file you submitted was empty" error. This means that the upload was submitted, but was perceived as 0 bytes long at the server.
Possibly related: Saibo: error numer 3: I said I tried to upload two files of which only one worked. The strange thing is: the file which worked is named now https://commons.wikimedia.org/wiki/File:Burning_eyes_smileyi.png but it is locally on my HDD burning eyes smileyb.png unless I am completely crazy
I can confirm that only one file makes it with Firefox 3.6.24 32-bit build on my Ubuntu 11.10 64-bit box. Looking at the POSTs in Firebug, all of them do indeed submit empty files except for one... Possibly something is mixing up the file objects...? All files make it ok on a more current Firefox 7.0.2.
Can reproduce in FF 3.6 on Windows and Ubuntu. If we can't fix this, we should blacklist multi-file selection for the 3.X branches. Increasing priority to "Normal".
That would need a probably simple blacklist and is unresolved for over 1.5 months despite I had directly on the deployment told this to Neil in IRC (AFAIK). Please only deploy new features if you have the manpower to support it it least a bit.
Created attachment 10571 [details] Patch to disable Firefox 3.6's multiple file inputs This fixes the problem by disallowing the multiple-file inputs on 3.6, after plenty of effort to fix it by enabling them.
For posterity: The bug is *not* that only one file is sent, but that only one POST request has any data in it--all of the files are sent in that request, in the same field, but the server-side only accepts one file at a time. The problem here appears to be that, for whatever UploadWizard is doing to separate the file inputs, Firefox 3.6 had not yet fully implemented the necessary features in either FileAPI or something else. This interesting caveat brings about such crazy results as, for example, the filename of the first file being preserved, but that file actually being populated with the contents of the last file, because the server side only reads that one.
Code review started: https://gerrit.wikimedia.org/r/7120
I assume this is also still a problem in 10.0.4 and 12.0? (As 3.6 is mentioned in the bug summary but 3.6 is EOLed.)
No, 3.6 appears to be the only problematic browser. Regardless of its status at Mozilla, there are still a lot of people using it--http://upsdell.com/BrowserNews/stat.htm says between 0.5% and 12% still use Firefox 3, which is still a pretty big number.
*** Bug 32481 has been marked as a duplicate of this bug. ***
Adding patch and patch-need-review keywords. Thanks, Mark.
(In reply to comment #9) > No, 3.6 appears to be the only problematic browser. Regardless of its status at > Mozilla, there are still a lot of people using > it--http://upsdell.com/BrowserNews/stat.htm says between 0.5% and 12% still use > Firefox 3, which is still a pretty big number. http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm shows 2.37% for FF 3.6, more than the largest Safari version.
Merged in commit 7763f2fb3f089e2843e3c3b641c1d2014df6336d
