Closed Bug 901955 Opened 7 years ago Closed 7 years ago

CSS animations not working for SVG opacity

Categories

(Core :: SVG, defect)

24 Branch
x86_64
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla26
Tracking Status
firefox23 --- unaffected
firefox24 + disabled
firefox25 + verified
firefox26 + verified

People

(Reporter: widmer, Assigned: jwatt)

References

Details

(Keywords: regression, Whiteboard: [bugday-20130918])

Attachments

(2 files)

Attached file example
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.
Attachment #786298 - Attachment mime type: text/plain → text/html
Would you be willing to use http://mozilla.github.io/mozregression/ to find a regression range?
Flags: needinfo?(widmer)
Component: Untriaged → SVG
Product: Firefox → Core
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.
Could also be bug 854765 or bug 875037.
Flags: needinfo?(widmer)
Keywords: regression
(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 :-\
OS: Linux → All
Okay, I know what's going on. Patch coming up shortly.
Attached patch patchSplinter Review
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)
https://hg.mozilla.org/mozilla-central/rev/1d64db569ebf
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla26
:jwatt - ping, is this ready for uplift ?
Flags: needinfo?(jwatt)
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
Attachment #789886 - Flags: approval-mozilla-beta?
Attachment #789886 - Flags: approval-mozilla-aurora?
Attachment #789886 - Flags: approval-mozilla-beta?
Attachment #789886 - Flags: approval-mozilla-beta+
Attachment #789886 - Flags: approval-mozilla-aurora?
Attachment #789886 - Flags: approval-mozilla-aurora+
Keywords: verifyme
Verified as fixed on:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Firefox/24.0 (20130806170643)
QA Contact: ioana.budnar
(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.
This was backed out from Fx24 in bug 907503.
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
Whiteboard: [bugday-20130918]
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).
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.