Bryan.TongMinh wrote:

We set a maximum size for which a thumbnail is rendered to 10MB; this should probably be lowered for SVGs, because an SVG of 1MB is already very complex.

SVG is tricky because there's very little relation between the file size and the rendering complexity. A very very tiny SVG can ssslllloooowwww things down in the extreme (especially if it applies filters) while a very large one might actually be very simple, with just a bunch of polygons that render fairly fast.

Not really sure what's a good way to handle this from our end; in theory it's the browser engine's responsibility to deal with image decoding and it *ought not* block the UI while it works.

Commenters on Commons have so far mentioned two images:

This fairly normal-sized digital photo JPG works fine for me in Firefox 6, Firefox 7, and Chrome 14:
https://commons.wikimedia.org/wiki/File:Tayga_Magazov.jpg

This fairly small SVG map takes a couple seconds to render in Firefox 6, but on Firefox 7 it HANGS MY BROWSER for at least 30 seconds before I get tired of killing it. Chrome 14 is fine with this one as well.
https://commons.wikimedia.org/wiki/File:Acadie_g%C3%A9n%C3%A9alogique.svg

There's probably a nasty browser regression in Firefox 7 there...

nilfanion wrote:

With regards to the two images mentioned on Commons, for me using Firefox 7: The JPG takes a second or two to render, while the SVG hangs.

Two ideas that may, or may not, be viable for a quickish fix on MediaWiki side: Lowering priority of the thumb so the UI won't freeze, or just disabling the thumb entirely for the relevant user agents.

I've filed an upstream bug for Firefox; I can confirm that the bug happens on Firefox 7/8/9 when loading the Acadie généalogique SVG image as a data URI, even with all the javascript taken out:

https://bugzilla.mozilla.org/show_bug.cgi?id=694165

Since this seems to be a low-level part of the browser system I don't see any way to tweak priority or anything -- but we may be able to work around it by loading the image in a slightly different way (skipping the data URIs).

r99653 on trunk temporarily disables SVGs from the client-side thumbnailing; needs merge/deploy.

This has been deployed; confirmed after reload that the evil SVG no longer gets thumbed & doesn't hang on commons.

Still needs a better fix, and to confirm if other image types have problems beyond short 1-2 seond pauses (which are still annoying)

Mozilla devs have a fix in progress for the SVG hang (not yet approved for landing on Firefox 8, but probably will soonish).

It looks like this hang is specific to SVG parsing -- if there are long hangs (more than a few seconds) on other file types I'll need examples to test with.

It's probably worth testing if createObjectURL[1] works where the data URI doesn't, so we don't have to blacklist FF 7... might also be faster than converting multi-megabyte files to/from base64.

Firefox 3.6 only supports the data URIs though, so probably should keep that code path anyway for compat with folks on the old stable release.

[1] https://developer.mozilla.org/en/DOM/window.URL.createObjectURL

(To clarify -- there are no plans for another Firefox 7.0.x point release, so FF 8 will be the earliest version to get the fix. Should land on beta before FF 8 hits release status; worst case it slips to 9 or so in a few weeks.)

nilfanion wrote:

Additional test files, all over 9.9MB:
http://commons.wikimedia.org/wiki/File:Raphael2.jpg
http://commons.wikimedia.org/wiki/File:Thomson1896page10StyleG.png
http://commons.wikimedia.org/wiki/File:Masivul_Piatra_Craiului.gif

In each case, uploading via Firefox 7 on my PC pauses the UI for 1-2 seconds.
The thumbnail takes longer to generate, but doesn't affect use of browser
beyond the 1-2 second period.

Its possible esoteric JPG/PNG/GIF may have issues I suppose, but looks like its SVG with a problem.

Ok, it looks like window.URL.createObjectURL *does* work around the SVG hanging issue, so I may be able to bring the SVG thumbing back.

Need to test to see if it reduces the pause time on GIF/JPEG images also; looks like there may also be some extra delay on JPEGs because we read the file out into a binary string to extract EXIF data from it.

r99840 on trunk uses window.URL.createObjectURL to work around the SVG data: URI hang on Firefox 7+, and re-adds thumbing of SVGs.

Will do some more tweaking & benching before landing back to UploadWizard and 1.18, there may be some other things adding unnecessary short pauses such as decoding the full file to a binary string even if the file isn't a JPEG and won't be expected to have EXIF rotation markers.

tagging bugs for Marcus to look at

Don't think we can do an automated qunit test for this as such... we could easily test *for* the firefox bug by dropping a hang case data: URI into an <img>, but that's what Mozilla's test suites are there for.

To test that the workaround runs without hanging would require interactively selecting a file with the <input type="file"> control; this could perhaps be done via Selenium (no current test-running infrastructure at WMF using this, unknown future) but cannot be done from content JS in the browser, which is where the qunit tests run.

Since the original hanging issue in UploadWizard was resolved by disabling client-side thumbnailing, I'm changing this bug to "Fix local SVG thumbnailing" and lowering its importance.

Right now, local thumbnailing doesn't work for me either in FF or Chrome. In UW it is disabled per the above, and on https://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=ownwork I get an endless spinner in Chrome, and a 0x0 thumbnail in Firefox when uploading an SVG.

(In reply to comment #15)

Right now, local thumbnailing doesn't work for me either in FF or Chrome. In UW
it is disabled per the above, and on
https://commons.wikimedia.org/w/index.php?title=Special:Upload&uselang=ownwork
I get an endless spinner in Chrome, and a 0x0 thumbnail in Firefox when
uploading an SVG.

Hmm, works for me on Special:Upload in Firefox 16.0.2 and Chrome 23.0.1271.64 on Mac OS X, and Firefox 16.0.2 on Fedora 17.

Tested with a copy of https://commons.wikimedia.org/wiki/File:Acadie_g%C3%A9n%C3%A9alogique.svg SVG source.

Yep, that file works for me as well. The file I tested with was generated by an app and may have contained some invalid markup; opening and saving it in Inkscape also made it preview locally in Special:Upload.

So then this is just about applying the same method implemented for Special:Upload in UploadWizard.

Change 929003 had a related patch set uploaded (by Legoktm; author: Legoktm):

[mediawiki/core@master] upload: Remove TODO fixed in 2011

https://gerrit.wikimedia.org/r/929003

Change 929003 merged by jenkins-bot:

[mediawiki/core@master] Remove TODO fixed in 2011 from upload.js

https://gerrit.wikimedia.org/r/929003