Bug 6141 - DOMCSSPrimitiveValue is always returning values in pixels when using getComputedStyle:
Summary: DOMCSSPrimitiveValue is always returning values in pixels when using getCompu...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: CSS (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Beth Dakin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-18 14:32 PST by Ohmson
Modified: 2006-04-22 12:23 PDT (History)
0 users

See Also:


Attachments
JS test case (303 bytes, text/html)
2006-02-17 14:33 PST, Alexey Proskuryakov
no flags Details
Patch (20.41 KB, patch)
2006-04-21 16:19 PDT, Beth Dakin
hyatt: review+
Details | Formatted Diff | Diff
Updated layout test (303 bytes, text/html)
2006-04-21 16:21 PDT, Beth Dakin
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ohmson 2005-12-18 14:32:49 PST
I get a DOMCSSStyleDeclaration when using -[DOMDocument getComputedStyle::]. From the 
declaration, I can get the DOMCSSValue when using -getPropertyCSSValue. In my case, I needed to find 
the CSS 'font-size' of an element.

The object returned in getPropertyCSSValue is actually a DOMCSSPrimitiveValue object. In my CSS file, I 
actually have 'font-size: 10pt;' but when I try to use -[DOMCSSPrimitiveValue primitiveType], it is always 
returning me DOM_CSS_PX

Maybe because the values are 'computed' and so everything is in one kind of metrics, 'px'...

But at least -[DOMCSSPrimitiveValue getFloatValue:DOM_CSS_PT] should have given me back the '10.0', 
instead of '13.3333'
Comment 1 Joost de Valk (AlthA) 2006-02-17 01:44:46 PST
It's getting the computed style, the final value is always in px effectively... I'm sorry, this is a wontfix.
Comment 2 Alexey Proskuryakov 2006-02-17 13:44:46 PST
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; }
Comment 3 Alexey Proskuryakov 2006-02-17 14:33:50 PST
Created attachment 6570 [details]
JS test case
Comment 4 Beth Dakin 2006-04-21 16:19:13 PDT
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.
Comment 5 Beth Dakin 2006-04-21 16:21:09 PDT
Created attachment 7888 [details]
Updated layout test
Comment 6 Dave Hyatt 2006-04-21 22:01:14 PDT
Comment on attachment 7887 [details]
Patch

r=me
Comment 7 Beth Dakin 2006-04-22 12:23:37 PDT
I committed the patch.