Fix and reinstate local SVG thumbnailing
Closed, ResolvedPublic


Author: nilfanion


The thumbnail generated as a preview on the upload form, on any Wikimedia site, causes Firefox to hang until it is created. With large files, especially SVGs, Firefox will be unresponsive.

If you select a large JPG to upload via , there is a noticeable delay before the preview thumbnail appears in the source file box. If the file is a large SVG the delay is *much* longer. Firefox will not allow completion of the upload, or any other activity, until the thumb is generated.

I'm using Firefox 7.0.1 on Windows XP, but other users have reported problems too: see . Disabling javascript in Firefox prevents the thumbnail generation, allowing upload as normal. IE does not have this issue at all - again because the preview thumbnail is not generated.

Version: 1.20.x
Severity: normal
OS: Windows 7
Platform: PC


bzimport set Reference to bz31643.
bzimport added a subscriber: Unknown Object (MLST).

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.

brion added a comment.Oct 12 2011, 4:12 PM

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.

brion added a comment.Oct 12 2011, 9:26 PM

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:

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.

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:

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)

brion added a comment.Oct 14 2011, 9:46 PM

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.


brion added a comment.Oct 14 2011, 9:49 PM

(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:

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.

brion added a comment.Oct 15 2011, 1:56 AM

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.

brion added a comment.Oct 15 2011, 2:28 AM

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 I get an endless spinner in Chrome, and a 0x0 thumbnail in Firefox when uploading an SVG.

brion added a comment.Nov 10 2012, 9:19 AM

(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
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 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.

TheDJ closed this task as "Resolved".Mar 29 2015, 10:08 PM
TheDJ claimed this task.
TheDJ added a subscriber: TheDJ.

To summarize, Upstream bug was fixed in FF 8, 3,5 years ago. A workaround patch was added for Special:Upload, we wanted to also apply that fix to UploadWizard, but never did it.

Since probably there is no longer anyone on FF7 anymore, I don't think it is very likely that we will ever need to implement the workaround for UploadWizard. Thus closing as resolved.

Add Comment