Closed Bug 1008598 Opened 5 years ago Closed 3 years ago
Animated SVG as background image not animating
STR: 1. Load http://philbit.com/SvgImagePerformance/backgroundImage.html 2. (optional) Zoom in so you can see the images better. EXPECTED RESULT: Images animating (spinning) ACTUAL RESULT: Images not animating. (Ignore the sliding back and forth; that's done with script, and is not the animation I'm talking about) Working in release build (29.0); broken in Nightly build: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 32.0a1 (2014-05-09) (Maybe a regression from bug 1002632?)
[getting regression range]
Regression window(m-i) Good: https://hg.mozilla.org/integration/mozilla-inbound/rev/01dd7c0d8f8d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140501092310 Bad: https://hg.mozilla.org/integration/mozilla-inbound/rev/9a6b434b34be Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140501093412 Pusjlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=01dd7c0d8f8d&tochange=9a6b434b34be Suspect:Bug 1002632
Thanks! That matches my findings. Taking; I'll look at this after the weekend.
Assignee: nobody → dholbert
Two facts I just noticed: (a) After reproducing, if I reload (not shift-reload), I get EXPECTED RESULTS. (b) I can reproduce in Firefox 29, using a local html file and a local SVG file. (and reloading fixes it there, too, per (a)) So this might be an existing race condition that bug 1002632 just exposed a bit more.
If I open the testcase in several tabs, only the first one is frozen -- but it updates its rendering (showing the animated image) if I force a repaint by e.g. switching to a blank tab and back, or especially if I switch to one of the functional tabs & back. Better, it updates smoothly (basically making the bug go away) if I instead open a copy of the testcase in a new *window*. All of this suggests that we're failing to set up the first document to send RefreshRequested() notifications to the image. (but subsequent documents send those notifications just fine)
Regression window about attachment 8420558 [details] Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/47b8ffe6ecc4 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130904025148 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/1c690d9998f7 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130904034048 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=47b8ffe6ecc4&tochange=1c690d9998f7 Suspect: Bug 911862
Ah, interesting that that attachment has a different regression window. Sounds like that might be a version of bug 935888, then. Let's use this bug here to track the more recent regression (which may have just been making bug 935888 easier to hit), and keep bug 935888 targeting the older issue. (That probably means we should obsolete attachment 8420558 [details] and reduce a testcase that better-exposes the recent regression (& only fails in builds from the past week or so, post-comment 2's regression window).)
Attachment #8420557 - Attachment description: (throbber SVG image, used in testcase) → (throbber SVG image, for use in testcases)
Ahh, OK, this makes sense. I think this is the same underlying issue as bug 935888. A few weeks ago, when SVG images had their own internal refresh-driver-ticks (pre-bug 1002632), you could effectively work around bug 935888 by forcing continuous repaints via e.g. backgroundPosition tweaks (since the image was greedily animating under the hood, and just failing to invalidate). But now that the image doesn't greedily animate anymore, that workaround no longer works. (not that it's really a useful workaround in the first place) Put another way: Documents that display an animated image are supposed to be hooked up to the image in at least two ways: (a) to *send* the image new timestamps & let the image update its internal animation state. (Until bug 1002632, we ignored these prompts and just let the image animate internally, greedily.) (b) to *receive* invalidations from the image, when there's something new to be painted. Bug 935888 revealed that we were failing to do part (b), and I think this bug reveals we're also failing to do part (a). (I suspect the two forms of registration happen via the same code-path, so it's probably the same underlying bug.) Marking this as depending on bug 935888 for now.
Unassigning, since this is less of a regression than I thought. (The testcase only worked in the first place because it happened to be doing bonus extra invalidation, per comment 11; without that additional scripted animation, it would've already been broken due to bug 935888. Hopefully someone (probably seth or jwatt or I) can get back into bug 935888 soon.
Assignee: dholbert → nobody
I ran into this when implementing bug 1194622 see attachment 8655825 [details]. We'll just use a plain <img src> to get the animation working.
I ran into the same bug. we use a loader with key frame animation as background image. that works even in IE10 but not in firefox.
I have the same issue. We are currently working on an UI-Framework that should support multiple themes. To be able to exchange the waiting animations and other stuff by css we use background svg images. It works fine in almost every browser, but can't be done in Firefox, because the animations are just not animated and only show the first frame.
the landing of bug 935888 has fixed this.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
I've managed to reproduce this issue on an older Nightly build (2014-05-10) with provided STR from comment 0. This is verified fixed on 50.0b2-build1 (20160926162149), running Windows 10 x64, Ubuntu 16.04 x64 LTS and Mac OS X 10.11.6.
You need to log in before you can comment on or make changes to this bug.