1008598 - Animated SVG as background image not animating

Status: VERIFIED FIXED

(Core :: Graphics: ImageLib, defect)

Description

[Daniel Holbert [:dholbert]]

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?)

Comment 1

[Daniel Holbert [:dholbert]]

[getting regression range]

Comment 2

[Alice0775 White]

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

Comment 3

[Daniel Holbert [:dholbert]]

Thanks! That matches my findings. Taking; I'll look at this after the weekend.

Comment 4

[Daniel Holbert [: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.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: (throbber SVG image, for use in testcases)

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (broken in old builds too; probably more of a testcase for bug 935888)

Comment 7

[Daniel Holbert [:dholbert]]

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)

Comment 8

[Alice0775 White]

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

Comment 9

[Daniel Holbert [:dholbert]]

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

Comment 10

[Alice0775 White]

Attachment: reduced.html

Comment 11

[Daniel Holbert [:dholbert]]

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.

Comment 12

[Daniel Holbert [:dholbert]]

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.

Comment 13

[Ed Lee :Mardak]

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.

Comment 14

[tomati]

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.

Comment 15

[Tobias Oelgarte]

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.

Comment 16

[Robert Longson [:longsonr]]

the landing of bug 935888 has fixed this.

Comment 17

[Ciprian Georgiu, Desktop QA]

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.