Large skew transform is rendered inconsistently




7 years ago
3 years ago


(Reporter: jruderman, Unassigned)


(Depends on: 1 bug, Blocks: 2 bugs, {testcase})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments)



7 years ago
Created attachment 590427 [details]
testcase (clicking should have no effect)
Confirmed with 64-bit Linux nightly:
 Mozilla/5.0 (X11; Linux x86_64; rv:12.0a1) Gecko/20120123 Firefox/12.0a1
OS: Mac OS X → All
Hardware: x86_64 → All


7 years ago
Blocks: 373610

Comment 2

3 years ago
Created attachment 8634856 [details]
testcase with smaller angle.svg

This bug is present for any skew angle with more than 6 significant digits, but is only evident on screen for large values - the attached testcase is the same as the original except for a smaller (but still pretty numerically large) angle.

The short version is that when transform is set via js the value stored in style is 23058.4297, but after the click and the subsequent (re-)BindToTree of the nsSVGElement, the style value gets reparsed (in case the baseURI changed), and this time the parser used only retains 6 significant digits, so a new nsAttrValue for transform is created with a value of 23058.4, and the difference between a skew angle of 23058.4297 and 23058.4 is noticeable on screen.

Some more detail:
When transform is initially set via js it's parsed using CSSParser, which parses all of the digits of the decimal angle number into a double, which then gets downcast to a float (whence the 23058.4297).
But in nsSVGElement::BindToTree after the click, the oldVal->ToString(stringValue) call winds up using Declaration's ToString method, which eventually calls nsCSSValue::AppendToString to serialize the angle value using nsAString's AppendFloat method, which only retains 6 significant digits, so the new nsAttrValue is given a value of 23058.4.

Feel free to take this one.


3 years ago
Depends on: 723376
You need to log in before you can comment on or make changes to this bug.