Summary: | DOMCSSPrimitiveValue is always returning values in pixels when using getComputedStyle: | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Ohmson <ohmson> | ||||||||
Component: | CSS | Assignee: | Beth Dakin <bdakin> | ||||||||
Status: | RESOLVED FIXED | ||||||||||
Severity: | Normal | ||||||||||
Priority: | P2 | ||||||||||
Version: | 420+ | ||||||||||
Hardware: | Mac | ||||||||||
OS: | OS X 10.4 | ||||||||||
Attachments: |
|
Description
Ohmson
2005-12-18 14:32:49 PST
It's getting the computed style, the final value is always in px effectively... I'm sorry, this is a wontfix. What about the final part of the report? It indeed looks strange that the specified unit type is ignored: double getFloatValue(unsigned short /* unitType */) const { return m_value.num; } Created attachment 6570 [details]
JS test case
Created attachment 7887 [details]
Patch
Here is a patch that fixes the bug. I talked through this design with Hyatt. Since we use getFloatValue() internally a lot, I created another version that still just returns m_value.num since that is what the internal callers expect and since passing in the type was clunky and unnecessary. It is also worth noting that the given test case does not contain the exact value we return. The test case expects that we render floating point pixels, but we round to integers. This causes the expected calculation to be off from the actual calculation. (It also means that our results, while accurate, do not match Firefox exactly.) I will upload a more accurate test in a minute.
Created attachment 7888 [details]
Updated layout test
Comment on attachment 7887 [details]
Patch
r=me
I committed the patch. |