Last modified: 2012-08-14 17:35:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T39150, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 37150 - UploadWizard broken in Safari 5
UploadWizard broken in Safari 5
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UploadWizard (Other open bugs)
unspecified
All All
: High major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-27 19:57 UTC by Erik Moeller
Modified: 2012-08-14 17:35 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Erik Moeller 2012-05-27 19:57:17 UTC
In Safari 5, UploadWizard currently will fail after selecting a file to upload. The console shows the following error message:

TypeError: 'undefined' is not an object (evaluating 'file.size').

This is triggered in line 32 in mw.FormDataTransport.js.
Comment 1 Mark Holmquist 2012-05-28 16:05:09 UTC
I have a hunch that this has to do with the new handling of uploads right away--some of the magic might have created empty Upload objects. I'll make sure we do proper emptying of the bins once we've thrown them out. Funny that no other browsers complained, though!
Comment 2 Mark Holmquist 2012-05-28 16:55:06 UTC
Turns out we weren't checking for FileApi functionality in our decision to use one upload handler or the other. This patch ought to do the trick: https://gerrit.wikimedia.org/r/9140

That being said, I haven't tested it, it would be nice to have a labs instance to test these sorts of things....
Comment 3 Erik Moeller 2012-05-28 21:27:41 UTC
Can you try testing it through BrowserStack or CrossBrowserTesting (either should allow you to set up a tunnel to localhost)?
Comment 4 Mark Holmquist 2012-05-28 22:08:03 UTC
I can tomorrow, but my browser at home doesn't like the Java applet for some reason.
Comment 5 Ryan Kaldari 2012-05-28 22:43:01 UTC
I've confirmed that this fixes the problem and doesn't break existing functionality. I've also reviewed and merged the change in Gerrit.

BTW, we do have virtual machines set up for testing the various versions of Explorer (https://secure.wikimedia.org/wikipedia/office/wiki/VirtualMachines), but we don't have one for Safari (since about half of the developers have it installed locally). I haven't had any trouble personally with BrowserStack in Firefox. Might want to make sure your Java runtime environment is fully up to date.
Comment 6 Mark Holmquist 2012-05-28 23:00:58 UTC
Kaldari, thanks for the help! I did apt-get update last night and apt-get install icedtea6-plugin openjdk-6-jre just this morning, so I doubt it's that--maybe I need to upgrade to openjdk-7, but it doesn't appear to be in my repositories. I hardly ever need Java on this machine anyway, so it's no problem. I know it works at the office.
Comment 7 Erik Moeller 2012-05-29 00:04:51 UTC
Confirmed working on test2; should therefore be fixed on live Commons after the Wednesday deployment.

Although now multi-file select doesn't work in Safari - not sure it ever did. It's such a useful feature that it may be worth the effort of trying to make it work with browsers with partial File API implementations.
Comment 8 Ryan Kaldari 2012-05-29 06:02:27 UTC
I don't believe multi-file select ever worked in Safari.
Comment 9 Mark Holmquist 2012-05-29 16:31:27 UTC
The new checks for multi-file select are actually checking for the requisite technology in the browser, so if UW doesn't let Safari do it anymore, it probably never worked....

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links