Page MenuHomePhabricator

Flickr upload stuck in "Uploading..."
Closed, ResolvedPublic

Description

After reading http://lists.wikimedia.org/pipermail/commons-l/2012-August/006641.html I thought I'd try it out on http://mwreview.wmflabs.org/wiki/index.php/Special:UploadWizard.

I tried uploading this photo: http://www.flickr.com/photos/craftybunny/88011957/
It goes into an infinite "Uploading..." for me[1].

No console errors.

Trying again when checking for HTTP requests I see a POST request to api.php with response {"options":"success"}. Though there is a response indeed, the request itself is marked as "Aborted / Cancelled" in the "Resources" tab of the Development Tools in Chrome.

Not sure what's going on, but it appears to be a logic problem (a missing error handler somewhere, causing state to get stuck eventhough the asynchronous action did in fact get back, just not with success) - aside from the fact that the api.php returns in error, which is another problem.

[1] Left it open for 20 minutes, this is not a slow thing or a time out. Polling resources, http requests and console messages, it seems like it died very early on (1-5 seconds in) and nothing happened after that.


Version: master
Severity: blocker

Details

Reference
bz39948

Related Objects

StatusAssignedTask
OpenNone
ResolvedNone

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:00 AM
bzimport added a project: UploadWizard.
bzimport set Reference to bz39948.
bzimport added a subscriber: Unknown Object (MLST).
Krinkle created this task.Sep 3 2012, 8:26 PM
TheDJ added a comment.Sep 3 2012, 8:39 PM

which browser ?

Chrome 21 (stable; no extensions enabled), Mac OS X 10.8.1

I seem to have the same problem on Firefox 15.0 on Windows. The upload gets stuck in the uploading phase. The last operation is the action=upload POST to api.php, ending with 200 OK.

However, the file seems to have reached the server, as it is in the upload stash (and the API result is result: "Success").

I was a bit surprised the API call requests format=jsonfm, which is what it gets in the result, but it seems this is normal in UW (“we use JSON in HTML because according to mdale, some browsers cannot handle just JSON”). Huh.

TheDJ added a comment.Sep 5 2012, 8:16 AM

BTW, this server has the "Refused to display document because display forbidden by X-Frame-Options." since recent UW changes.

TheDJ added a comment.Sep 5 2012, 8:20 AM

and yes, we should figure out what exactly it was that made mdale go with jsonfm instead of json, it's weird and should be fixed in my opinion if in any way possible.

TheDJ added a comment.Sep 5 2012, 8:23 AM

And our response handler should detect the X-Frame-Options header, so we can give proper feedback.

TheDJ added a comment.Sep 5 2012, 10:00 AM

Added api check for x-frame-options in https://gerrit.wikimedia.org/r/22708

I've added some additional error handling to Flickr uploading. Please retest. BTW, it is currently turned on on test.wikipedia.org, so feel free to test it there:
https://test.wikipedia.org/wiki/Special:UploadWizard

Tested using Crossbrowsertesting.com for said configurations

The photo uploads on https://test.wikipedia.org/wiki/Special:UploadWizard

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.
Gilles lowered the priority of this task from Unbreak Now! to High.Dec 4 2014, 11:20 AM