Page MenuHomePhabricator

UploadWizard can't upload more than one file
Closed, DeclinedPublic

Description

When uploading a series of files using UploadWizard, only the first file uploads properly. Throbbers spin continuously for the remaining files, which do not upload at all, even if I've waited for 15 to 20 minutes. I'm using the latest version of Mozilla Firefox.


Version: master
Severity: major
OS: Windows 7
Platform: PC

Details

Reference
bz46845

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:39 AM
bzimport added projects: UploadWizard, TestMe.
bzimport set Reference to bz46845.
bzimport added a subscriber: Unknown Object (MLST).

Mozilla Firefox 19.0.2 (soon to be something else on my computer, as when I checked what the version number was it triggered a download of a newer update ...).

This works for me locally... If you go to Tools -> Web Developer -> Web Console and trigger the bug, do any errors come up in the JS console?

Here is what I got:

[01:05:47.867] GET http://commons.wikimedia.org/w/api.php?action=tokens&format=json&type=edit [HTTP/1.0 200 OK 609ms]
[01:05:48.405] TypeError: file is undefined @ http://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=false&lang=en&modules=ext.uploadWizard&skin=vector&version=20130403T023115Z&*:46
[01:05:48.476] GET http://commons.wikimedia.org/w/api.php?action=tokens&format=json&type=edit [HTTP/1.0 200 OK 359ms]
[01:05:48.789] TypeError: file is undefined @ http://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=false&lang=en&modules=ext.uploadWizard&skin=vector&version=20130403T023115Z&*:46
[01:05:48.858] GET http://commons.wikimedia.org/w/api.php?action=tokens&format=json&type=edit [HTTP/1.0 200 OK 407ms]

[01:05:49.198] TypeError: file is undefined @ http://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=false&lang=en&modules=ext.uploadWizard&skin=vector&version=20130403T023115Z&*:46

[01:06:31.808] GET http://commons.wikimedia.org/w/api.php?action=query&format=json&prop=stashimageinfo&siifilekey=11c1iu0exaxc%2Eqwedk8%2E974766%2Ejpg&siiprop=url&siiurlwidth=100&siiurlheight=100 [HTTP/1.0 200 OK 1606ms]
[01:06:32.716] Error in parsing value for 'margin-left'. Declaration dropped. @ http://commons.wikimedia.org/wiki/Special:UploadWizard
[01:06:32.716] Error in parsing value for 'margin-top'. Declaration dropped. @ http://commons.wikimedia.org/wiki/Special:UploadWizard
[01:06:33.509] GET http://commons.wikimedia.org/wiki/Special:UploadStash/thumb/11c1iu0exaxc.qwedk8.974766.jpg/100px-11c1iu0exaxc.qwedk8.974766.jpg [HTTP/1.0 200 OK 4664ms]

The main problem seems to be the "Error in parsing value" for 'margin-left' and 'margin-top'. There is a red number for both of these errors that keeps increasing.

By the way, I am now using Mozilla Firefox 20.0.

It looks more concerning that something called "file" is undefined. That's probably the error that's causing the trouble.

If you could do exactly what you did above, but at https://commons.wikimedia.org/wiki/Special:UploadWizard?debug=true for clarity, we can probably even mark this as an easy bug with the resulting information.

Also, you could use a pastebin for the error contents and maybe make this page more readable, if you preferred :) WMF likes http://dpaste.com for example.

OK, I'm trying to upload the four JPEG files again at https://commons.wikimedia.org/wiki/Special:UploadWizard?debug=true. However, this time the only error message that is appearing is the "Error in parsing value" for 'margin-left' and 'margin-top' one. Will see if I can figure out how to get dpaste.com to work.

Iiinteresting. And the files still won't upload?

Yup. Stopped the experiment after about five minutes. It really shouldn't take that long to load four files, should it?

A few more details: only the first file has a green arrow and the thumbnail of the file. The remaining three files have a continuously rotating throbber, and the indicator at the bottom of the web page indicating how much time more it will take to upload the remaining files jumps about rather wildly.

mtraceur: Any other ideas for the reporter how to provide more info here that helps debugging this?

I really don't - why a parse error on a CSS rule would stop downloads is beyond me.

If reporter could find the value of margin-left that was causing the error, maybe we could try to find out what sets it to that, but other than that I don't know.

Can you explain how one can "find the value of margin-left"?

By the way, the following comments were posted on the Wikimedia Commons Village Pump today (http://commons.wikimedia.org/wiki/Commons:Village_pump#Browser_Issue?): "Is anyone having difficulty with Upload Wizard and a few other features using Firefox (but in Chrome it all works)? I want to figure out if it's a system thing or my computer. Thanks--Godot13 (talk) 00:45, 13 April 2013 (UTC) ... I was about to ask the same question (for MS Internet Explorer): the Upload Wizard just doesn't load. Highly frustrating... :( MartinD (talk) 07:55, 14 April 2013 (UTC)" Not sure if it's a related problem.

I tried using the UploadWizard on Chrome and did not encounter any problems.

There were several reports at https://commons.wikimedia.org/wiki/Commons:Upload_help (e.g. ==Keine Reaktion auf "Upload file"== or ==Assistent zum Hochladen== or ==Custom license box chokes on tag redirects?== or ==Upload Wizard== or ==WIZARD==) and I always suggested to turn off UploadWizard. Debugging it (or asking people to do so) is simply no fun.

vvv214wth wrote:

I've tried it on chrome and it's ok.

(In reply to comment #14)

I tried using the UploadWizard on Chrome and did not encounter any problems.

Could you verify if it now works for you in FF so we can have a better resolution for this bug?

No, I just tried it using Firefox 20.0.1 and only two of the five files I selected (the first and the last file) uploaded successfully. For the three remaining files, the throbbers are spinning but nothing seems to be happening.

Strange, I am using Win 7, FF 20.0.1 and everything works fine for me, I tested this on commons as well as on my local wiki running upto date core and UploadWizard.

Smuconlaw, if the files aren't too big, maybe upload them here so we can test further and maybe we can make some progress on this. We suspect it may just be that your connection accidentally fails sometime midway through the upload and we can't complete it, but we'd like to make sure it's not something about these particular files causing trouble.

I think this bug can be closed. I am now using Mozilla Firefox 23.0.1, and UploadWizard seems to be working fine. I guess some update to the browser may have solved the issue.

(In reply to comment #21)
If that is the case, the bug should not be closed and the devs should run a test against old versions of Firefox. My bet is that "isSliceAvailable" returns false results for that version of FF (19.0.2 ?)

https://github.com/wikimedia/mediawiki-extensions-UploadWizard/blob/master/resources/mw.fileApi.js#L51

@Rainer Rillke: that's a good point. I suppose it is conceivable that there are still people using older versions of Firefox.

As I mentioned in May, I was still having problems with Firefox 20.0.1.

(In reply to comment #22)
Well mabe not, if "file" is undefined...

Did you delete the files immediately after selecting them in UpWiz? Do you have some software running that closes file handles (just if you know...)? Were all files readable (without administrative elevation)?

Which version of Windows 7 are you using? Home premium, professional, ... 32/64 bit?

  1. No, I didn't delete the files after selecting them in the UploadWizard.
  1. No idea whether any software was closing file handles. I had Windows Explorer open to view the files.
  1. Yes, I could see the files using Windows Explorer. However, I'm the administrator of my laptop so I may have been logged in with administrator privileges.
  1. I am using Windows 7 Enterprise with Service Pack 1, and a 32-bit operating system.

(In reply to comment #24)
Do you have software running that trick about your browser version (e.g. claiming to be "Firefox 8" while actually being Firefox 20)?

(In reply to comment #12)
The CSS error happens if something is wrong with the $fileInputCtrl:
https://github.com/wikimedia/mediawiki-extensions-UploadWizard/blob/6b1ba63356be72188bf9fb95f6d165381ee8f9de/resources/mw.UploadWizardUploadInterface.js#L555

  • I guess that _this.$fileInputCtrl.width() returns NaN or similar.

I suggest only pushing things that really exist there:
https://github.com/wikimedia/mediawiki-extensions-UploadWizard/blob/6b1ba63356be72188bf9fb95f6d165381ee8f9de/resources/mw.UploadWizardUploadInterface.js#L299

That may resolve the issue. Patch for this follows.

While testing I found a bug with very similar symptoms if the read-permissions are denied (but directory listing is allowed), an empty request is issued and the result is null, consequently doing result.error at
https://github.com/wikimedia/mediawiki-extensions-UploadWizard/blob/6b1ba63356be72188bf9fb95f6d165381ee8f9de/resources/mw.UploadWizardUpload.js#L175

will trigger an error and the throbber spins forever.

(In reply to comment #27)
No, I don't use any such software on my computer.

Gilles raised the priority of this task from High to Unbreak Now!.Dec 4 2014, 10:21 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.

I think this problem was diagnosed in another bug to be caused by Firefogg.

Gilles lowered the priority of this task from Unbreak Now! to High.Dec 4 2014, 11:20 AM