Closed Bug 828286 Opened 7 years ago Closed 7 years ago

center of svg animation is incorrect on industrial demo at zamek.pmmf.hu, ever since SVG display lists became enabled

Categories

(Core :: SVG, defect)

17 Branch
defect
Not set

Tracking

()

VERIFIED FIXED
mozilla21
Tracking Status
firefox18 --- affected
firefox19 - verified
firefox20 - fixed
firefox21 --- fixed
firefox-esr17 --- wontfix
b2g18 --- wontfix

People

(Reporter: zamek42, Assigned: longsonr)

References

()

Details

(Keywords: regression, testcase)

Attachments

(3 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Linux; Android 4.0.3; GT-P5100 Build/IML74K) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.166  Safari/535.19

Steps to reproduce:

In my gwt app has some rotated svg animation. 


Actual results:

Since ff17.0. the center of rotation slipped. Affected with 17.0.1 and 18.0 in linux,android and windows too. Ff 15 and 16 worked well, the error comes in ff17.0. CHrome,opera  works well.


Expected results:

You can test it on http://zamek.pmmf.hu:8080/gwt/Argus.html
There are some pumps on the first page(pumping station), which change their states randomly.
Duplicate of this bug: 828292
Component: Untriaged → SVG
Product: Firefox → Core
Still broken on trunk.

zamek
Is it possible you could create a simpler example with just the one item rotating that isn't dynamically created?

Also would you be willing to a regression range?

https://quality.mozilla.org/docs/bugzilla/guide-to-triaging-bugs-for-firefox/finding-a-regression-window/

type about:buildconfig in the address bar in the last good and subsequent first bad build and post the Built from link please.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(zamek42)
Last good nightly: 2012-08-02
First bad nightly: 2012-08-03

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=588424024294&tochange=89dcadd42ec4

Looks like a regression from bug 776054.
Blocks: 776054
Flags: needinfo?(zamek42)
(In reply to Daniel Holbert [:dholbert] from comment #3)
> Looks like a regression from bug 776054.

Confirmed w/ targeted builds. b077c43a4306 is broken, while its parent (9dc8f2dc324a) is WFM.
(In reply to Robert Longson from comment #2)
> zamek
> Is it possible you could create a simpler example with just the one item
> rotating that isn't dynamically created?

echoing this ^^^ a simpler testcase would be very helpful in figuring out what's going on here.
Keywords: testcase-wanted
Summary: center of svg animation slips → center of svg animation is incorrect on industrial demo at zamek.pmmf.hu, ever since SVG display lists became enabled
ok I will create a simple test app, pls. give me a day.
I made a simple test application, you can reach it: 
http://zamek.pmmf.hu:8080/svgtest/Svgtest.html
It looks like the SVG is generated dynamically, no?

Weird thing, if I use the Inspector tool, the blue wheel goes back instantaneously to its normal fixed rotation position.
no, it is a simple svg file. I used gwt-svg library from http://www.vectomatic.org/libs/lib-gwt-svg . Do you need the original svg file? 
I uploaded it to http://vili.pmmf.hu/~zamek/test.svg
(In reply to zamek from comment #9)
> no, it is a simple svg file. I used gwt-svg library from
> http://www.vectomatic.org/libs/lib-gwt-svg
> Do you need the original svg file? 
> I uploaded it to http://vili.pmmf.hu/~zamek/test.svg

Thanks! That SVG file renders just fine on its own, FWIW... That's interesting. It looks like GWT is doing some server-side munging of that SVG, and then dynamically re-generating it on the client through JS.  (It ends up being inserted directly into the page's DOM, as a child of the div with id "gwt-HTML", which goes inside the <td> with id "nameFieldContainer").

The dynamic part appears to be important, since the static SVG renders correctly, and a saved snapshot of the web page (as "web page, complete") renders correctly, too.

> Weird thing, if I use the Inspector tool, the blue wheel [snaps to the right spot]

I see that, too.  I have to have actually inspect _something in the SVG_ (e.g. the <svg> node itself) to fix things, though.  The bug stays broken if I simply open the inspector tool w/ Tools | Web Developer | Inspector, and it also stays broken if I click any of the ancestors of the <svg> element in the inpsector's HTML-markup view of the page structure.
lib-gwt-svg is made by Lukas Laag. I try to ask him to help me to solve it.
Cool.  To be clear, there's definitely a Firefox bug here -- it's just being triggered by the specific things that lib-gwt-svg does.

In the meantime: if you happen to work around this on your production server, it'd be awesome if you could leave your testcase (from comment 7) accessible and "still broken", so we can investigate more.  (Alternately: is it fairly easy for someone to save your static SVG file and lib-gwt-svg and set up a server that will reproduce this locally for themselves?)
Attached file sample using DOMParser (obsolete) —
Hi. I am the author of lib-gwt-svg, a library which adds SVG support to GWT. So it is a client-side javascript library, written in Java and compiled to javascript by GWT. I have attached a sample which reproduces the problem without GWT or lib-gwt-svg. The sample parses an SVG document using DOMParser, then inserts it in the DOM. In the case of the real application, the SVG comes through XMLHttpRequest. To simplify, I have added it as a string literal.
Attachment #702976 - Attachment mime type: text/plain → text/html
Excellent -- thanks for creating & attaching that, Lukas!
Attached file example simplified
Attachment #702976 - Attachment is obsolete: true
If I take the <svg> element and put that in as markup then inserting the path and animateTransform works OK.
OS: Linux → All
Attached file with explicit -moz-transform-origin (obsolete) —
Somehow -moz-transform-origin is getting set to 50% 50% in the non-working case. This despite it being set in svg.css e.g. http://mxr.mozilla.org/mozilla-central/source/layout/svg/svg.css#58
Attachment #704207 - Attachment is obsolete: true
So nsDocument::StartDocumentLoad has this:

    // We need to disable script & style loading in this case.
    // We leave them disabled even in EndLoad(), and let anyone
    // who puts the document on display to worry about enabling.

    // Do not load/process scripts when loading as data
    ScriptLoader()->SetEnabled(false);

    // styles
    CSSLoader()->SetEnabled(false); // Do not load/process styles when loading 

So when NS_NewSVGElement calls nsDocument::EnsureCatalogStyleSheet, that method does nothing.

The only callers to nsDocument::EnsureCatalogStyleSheet are mathml and svg. Surely mathml and svg should load their stylesheets even when loaded as data.
Assignee: nobody → longsonr
Attached patch patchSplinter Review
Attachment #704239 - Flags: review?(dholbert)
This is how mathml does it FWIW. mxr.mozilla.org/mozilla-central/source/content/mathml/content/src/nsMathMLElement.cpp#82
This should work better, moved the stylesheet load till after the base class call. 

https://tbpl.mozilla.org/?tree=Try&rev=78d9e8339286
https://hg.mozilla.org/mozilla-central/rev/d837646f7676
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Comment on attachment 704239 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 776054
User impact if declined: Incorrect rendering of SVG if the data has been imported using importNode
Testing completed (on m-c, etc.): landed with reftest
Risk to taking this patch (and alternatives if risky): Low, SVG implementation now matches mathml
String or UUID changes made by this patch: none
Attachment #704239 - Flags: approval-mozilla-beta?
Attachment #704239 - Flags: approval-mozilla-aurora?
This is not a regression in FF18, so this isn't very critical and there's no need to track. That being said, we will accept this low risk uplift if landed today (in time for Beta 3).
Attachment #704239 - Flags: approval-mozilla-beta?
Attachment #704239 - Flags: approval-mozilla-beta+
Attachment #704239 - Flags: approval-mozilla-aurora?
Attachment #704239 - Flags: approval-mozilla-aurora+
Landed on aurora/beta (fixing this in Firefox 20 & 19):
  https://hg.mozilla.org/releases/mozilla-aurora/rev/256a897249c7
  https://hg.mozilla.org/releases/mozilla-beta/rev/9b6d51622167

Also: Setting status flags for firefox-esr17 & b2g18 to 'affected' -- based on comment 0, this was a regression in Firefox 17, so both of those releases should exhibit this bug.
Verified as fixed on Firefox 19 beta 3 (20130123083802):
Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0
Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0
Depends on: 816523
Marking this as wontfix for esr/b2g18 given this is not a security issue or ESR-specific regression
Hi all,

I've download the new ff19 and I see, all are working well.
Many thanks to you!

By zamek
Glad to hear it! Thanks very much for filing the bug & for your help in tracking down what was going on!

[Marking as verified fixed per comment 33]
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.