Bug 1492338 Comment 9 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I just confirmed that on my Mac machine, the remaining (negligible) difference between the select boxes is simply due to rounding error and conversion issues.

All three select elements have width=2286 app units, but their x positions var and aren't necessarily pixel-aligned (in layout).  (In particular, they have x=480, 3006, and 5532.)  And the API in the testcase here, `getBoundingClientRect`, produces its resulting rect in an "x, y, XMost(), YMost()" representation:
https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/dom/base/Element.cpp#1036
https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/dom/base/DOMRect.cpp#83-84

So: even for equally-sized objects,  they may end up with a subtly different `getBoundingClientRect` rect-widths if they're positioned at spots that trigger rounding behavior.

So: the remaining differences here are negligible and well-understood, and are in fact not a difference at all at the `nscoord` level.  And the significant "real" differences from comment 0 and comment 1 have gone away.  So, this is WORKSFORME.
I just confirmed that on my Mac machine, the remaining (negligible) difference between the select boxes is simply due to rounding error and conversion issues.

All three select elements have width=2286 app units, but their x positions var and aren't necessarily pixel-aligned (in layout).  (In particular, they have x=480, 3006, and 5532.)  And the API in the testcase here, `getBoundingClientRect`, produces its resulting rect in an "x, y, XMost(), YMost()" representation (where XMost() = x + width):
https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/dom/base/Element.cpp#1036
https://searchfox.org/mozilla-central/rev/f8b11433159cbc9cc80500b3e579d767473fa539/dom/base/DOMRect.cpp#83-84

So: even for equally-sized objects,  they may end up with a subtly different `getBoundingClientRect` rect-widths if they're positioned at spots that trigger rounding behavior.

So: the remaining differences here are negligible and well-understood, and are in fact not a difference at all at the `nscoord` level.  And the significant "real" differences from comment 0 and comment 1 have gone away.  So, this is WORKSFORME.

Back to Bug 1492338 Comment 9