firefox does not render correctly SVG animations
Categories
(Core :: SVG, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox-esr68 | --- | unaffected |
| firefox72 | --- | wontfix |
| firefox73 | --- | wontfix |
| firefox74 | --- | verified |
| firefox75 | --- | verified |
People
(Reporter: dvoreader, Assigned: emilio)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
firefox vs chrome
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:72.0) Gecko/20100101 Firefox/72.0
Steps to reproduce:
in the w3schools SVG tutorial, there is an example of SVG animation, which firefox does not render correctly at all, as compared with google chrome.
the test case is as follows:
(taken from here https://www.w3schools.com/graphics/tryit.asp?filename=trysvg_ellipses)
<!DOCTYPE html>
<html>
<body>
<p><strong>Note:</strong> This example does not work in Internet Explorer and Safari.</p>
<svg width="100%" height="300px">
<g id="R1" transform="translate(250 250)">
<ellipse rx="100" ry="0" opacity=".3">
<animateTransform attributeName="transform" type="rotate" dur="7s" from="0" to="360" repeatCount="indefinite" />
<animate attributeName="cx" dur="8s" values="-20; 220; -20" repeatCount="indefinite" />
<animate attributeName="ry" dur="3s" values="10; 60; 10" repeatCount="indefinite" />
</ellipse>
</g>
<use xlink:href="#R1" transform="rotate(72 390 150)" />
<use xlink:href="#R1" transform="rotate(144 390 150)" />
<use xlink:href="#R1" transform="rotate(216 390 150)" />
<use xlink:href="#R1" transform="rotate(288 390 150)" />
</svg>
</body>
</html>
Actual results:
incorrect visual animation, ellipse did not changed their size and rotation center, and the image smears on the screen
Expected results:
the ellipses should grow to be fat, and no smearing effect
|
||
Comment 1•6 years ago
|
||
I can reproduce the issue on Nightly74.0a1 Windows10 if HWA is disabled.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2ad581fafc85ab939d75f7aa1a2f901f45ecb113&tochange=21b3ac9c491755466306d68e1e198a6891c0e561
|
||
Updated•6 years ago
|
|
||
Comment 3•5 years ago
|
||
Hi Violet and/or Robert: Might one of you be able to look into this regression? It looks like it's fallout from bug 1383650. If not we will try to get someone on the layout team to investigate further. Thank you!
|
||
Comment 4•5 years ago
|
||
Looks like the animations work properly on WebRender, FWIW.
|
Assignee | |
Comment 5•5 years ago
|
||
I can poke.
|
|
Assignee | |
Comment 6•5 years ago
|
||
If we reconstruct frames due to some other reason, we will never get to the
DidSetComputedStyle bit that would clear it for us on change.
This is all in all very unfortunate, since I think the fact that we reconstruct
frames so aggressively is a bug anyway (this comes from this bit in
SVGAnimatedTransformList):
I think we are supposed to reconstruct only once at most, but I may be crazy :^)
Will look at that in a separate bug though, this is the most minimal change that
addresses the regression.
An alternative (equally low-risk) would be to clear cached paths also in the
case where there's no old computed style in nsSVGGeometryFrame...
|
|
Assignee | |
Comment 7•5 years ago
|
||
The optimization here was trying to avoid reconstructing in some cases when we
started animating a transform. Unfortunately it wasn't handling the transform
animations properly, which means that once it decided that adding the
transform value needed a reconstruction, it was deciding that changing it also
needed.
Which means that we reconstructed the frames once per animation frame, which is
pretty sad.
While fixing the optimization, also use a more comprehensive change hint, the
one that we use for transform property changes as well.
|
||
Comment 10•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/f484cfbf86b4
https://hg.mozilla.org/mozilla-central/rev/167e8d51f31d
|
||
Comment 11•5 years ago
|
||
Can we let this ride to 75 or would you like to uplift to beta?
|
|
Assignee | |
Comment 12•5 years ago
|
||
Comment on attachment 9128405 [details]
Bug 1610171 - Clear animated paths when SVG lengths change. r=longsonr,violet,dholbert
I think the first patch should be worth uplifting. The second is effectively an optimization.
Beta/Release Uplift Approval Request
- User impact if declined: Some SVG animations won't play correctly.
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: Yes
- If yes, steps to reproduce: comment 0
- List of other uplifts needed: none
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Restores previous behavior, reorders one line.
- String changes made/needed: none
|
|
Assignee | |
Updated•5 years ago
|
|
||
Comment 13•5 years ago
|
||
Comment on attachment 9128405 [details]
Bug 1610171 - Clear animated paths when SVG lengths change. r=longsonr,violet,dholbert
Small patch for SVG correctness, verified on Nightly, it seems low risk so uplift approved for 74.0b8, thanks.
|
||
Comment 14•5 years ago
|
||
| bugherder uplift | ||
|
||
Updated•5 years ago
|
|
||
Comment 15•5 years ago
|
||
I have reproduced the issue on Firefox 73.0.1 and Firefox Beta 74.0b7 on Windows 10, MacOS 10.15 and Ubuntu 18.04.
I've also verified it on Firefox Beta 74.0b8 (20200225213605) and Firefox Nightly 75.0a1 (20200225214332) and the issue has been fixed.
Description
•