Closed Bug 1008598 Opened 5 years ago Closed 3 years ago

Animated SVG as background image not animating


(Core :: ImageLib, defect)

Not set



Tracking Status
firefox31 --- unaffected
firefox32 --- affected
firefox50 --- verified


(Reporter: dholbert, Unassigned)


(Blocks 1 open bug, )


(Keywords: regression, testcase)


(2 files, 1 obsolete file)

 1. Load
 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)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140501092310
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140501093412

Suspect:Bug 1002632
OS: Linux → All
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]
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130904025148
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20130904034048

Suspect: Bug 911862
Blocks: 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 #8420558 - Attachment description: testcase 1 → testcase 1 (broken in old builds too; probably more of a testcase for bug 935888)
Attachment #8420558 - Attachment is obsolete: true
Attachment #8420557 - Attachment description: (throbber SVG image, used in testcase) → (throbber SVG image, for use in testcases)
See Also: → 935888
Attached file reduced.html
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.
Depends on: 935888
See Also: 935888
Keywords: testcase
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
Blocks: 1194622
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.
Closed: 3 years ago
Resolution: --- → FIXED
Flags: qe-verify+
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.
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.