Bug 30238
| Summary: | getComputedStyle-transform.html accidentally relies on float formatting details | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Evan Martin <evan> |
| Component: | CSS | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | Normal | CC: | darin, simon.fraser |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | PC | ||
| OS: | OS X 10.5 | ||
| Bug Depends on: | |||
| Bug Blocks: | 18994 | ||
Evan Martin
Relevant code:
// set one of our test transforms
testBox.style.webkitTransform = curTest.transform;
// read back computed style
var oldTransform = window.getComputedStyle(testBox).webkitTransform;
// set that matrix() back on the element
testBox.style.webkitTransform = oldTransform;
// read back computed style
var computedTransform = window.getComputedStyle(testBox).webkitTransform;
Suppose the following.
In step 1, when when we apply the transform one of the elements of the underlying matrix ends up being 0.23000005.
In step 2, when we read it back as a string, WebKit passes it through a printf(), which prints it to 6 significant digits as "0.230000".
In step 3, when we write it out again, that that string is parsed into the float 0.23.
In step 4, when it's read out again, it's now the string "0.23".
I ran into this in fixing float handling. I'd like to remove the second two lines of the above code (the test input has a string for the expected output). What do you think?
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Simon Fraser (smfr)
I think the test should stay the same, but we should round when printing the output and comparing with the expected values.
Evan Martin
The strings in question look like
"matrix(1, 0.36397, -0.842288, 1, 0, 0)"
So are you suggesting parsing those strings into separate fields?
Or can I read each field of the matrix as a float in js code, like by doing domnode.webKitTransform.<something here>?
Evan Martin
Oh, I think I found a better option: printf is actually specified to have this behavior (where trailing significant digits are chopped if they are 0). I think I can hack my float-printer to emulate it.
Evan Martin
(I still think the test is kinda wrong for the reason I mentioned though.)