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.

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.

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.

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

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

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.

Excellent -- thanks for creating & attaching that, Lukas!

If I take the <svg> element and put that in as markup then inserting the path and animateTransform works OK.

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

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.

This is how mathml does it FWIW. mxr.mozilla.org/mozilla-central/source/content/mathml/content/src/nsMathMLElement.cpp#82

Comment on attachment 704239 [details] [diff] [review] patch Nice!

This should work better, moved the stylesheet load till after the base class call. https://tbpl.mozilla.org/?tree=Try&rev=78d9e8339286

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

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

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

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]