Closed Bug 901955 Opened 7 years ago Closed 7 years ago
CSS animations not working for SVG opacity
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20130806004002 Steps to reproduce: Create an SVG element and try to animate its opacity style property with CSS3. Actual results: Animation does not work; opacity change can be observed only when the element is clicked. At the same time, similar animation works OK for HTML <div>. I've been using Firefox 24a2 for a while, and this issue has appeared just recently (round Aug 1 IIRC). Firefox 25 nightly shows the same. In Firefox 23, everything works OK. Expected results: SVG element should fade in/out smoothly.
Would you be willing to use http://mozilla.github.io/mozregression/ to find a regression range?
Last good nightly: 2013-05-25 First bad nightly: 2013-05-26 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7a2f7a45819a&tochange=0fed3377c839 Makes me suspect bug 875175.
(In reply to Cork from comment #2) > Last good nightly: 2013-05-25 > First bad nightly: 2013-05-26 > > Pushlog: > http://hg.mozilla.org/mozilla-central/ > pushloghtml?fromchange=7a2f7a45819a&tochange=0fed3377c839 Confirming. Don't know why I had an impression that it broke just a week ago :-\
Assignee: nobody → jwatt
Okay, I know what's going on. Patch coming up shortly.
This used to work because nsSVGPathGeometryFrame::DidSetStyleContext used to blindly invalidate and reflow, so we'd always invalidate for an opacity property change. Bug 854765 got rid of that code, and for opacity changes we now rely on DLBI. Unfortunately that breaks down when the SVG opacity optimization kicks in. The optimization is that if 'opacity' is set on an nsSVGPathGeometryFrame but nsSVGUtils::CanOptimizeOpacity() returns true, then we avoid creating a layer (previously, more directly avoided creating and compositing an offscreen surface) by treating the 'opacity' as 'fill-opacity' or 'stroke-opacity'. More specifically, nsIFrame::BuildDisplayListForStackingContext does not create an nsDisplayOpacity display item. As a result, DLBI can't invalidate for the change. The simplest thing to do in order to keep this safe for beta is to invalidate the frame in DidSetStyleContext in the case that the old and new 'opacity' is different and nsSVGUtils::CanOptimizeOpacity() returns true.
Attachment #789886 - Flags: review?(roc)
Attachment #789886 - Flags: review?(roc) → review+
:jwatt - ping, is this ready for uplift ?
Comment on attachment 789886 [details] [diff] [review] patch Yes. [Approval Request Comment] Bug caused by (feature/regressing bug #): bug 854765 User impact if declined: broken SVG Testing completed (on m-c, etc.): been on m-c for days Risk to taking this patch (and alternatives if risky): very low String or IDL/UUID changes made by this patch: none
Verified as fixed on: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (20130806170643)
(In reply to Ioana Budnar, QA [:ioana] from comment #13) > Verified as fixed on: > Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 > (20130806170643) Correct build ID for the build with the fix: 20130822154523. On the one in comment 13 the bug does reproduce.
Also verified on Firefox 24 beta 5 on Mac OSX 10.7.5 and Ubuntu 13.04 64bit.
Verified as fixed on Firefox 25: Mac OS X 10.8.4 - 20130912004004 Ubuntu 13.04 - 20130911004006 Windows 7 - 20130912004004
Looks like the fix works on Firefox Nightly 27.0: Trisquel GNU/Linux 6.0 64bit- 20130918030202
Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:26.0) Gecko/20100101 Firefox/26.0 Verified as fixed on latest Aurora 26.0a2 (buildID: 20131009004001) and latest Nightly 27.0a1 (buildID: 20131008030202).
You need to log in before you can comment on or make changes to this bug.