Last modified: 2012-12-27 00:40:53 UTC
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.
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.
BTW, this server has the "Refused to display document because display forbidden by X-Frame-Options." since recent UW changes.
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.
And our response handler should detect the X-Frame-Options header, so we can give proper feedback.
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
