1977306 - Consistently getting a different value from getBoundingClientRect in Firefox compared to Chromium or Safari browsers

Status: RESOLVED INVALID

(Core :: Layout: Text and Fonts, defect)

Description

[Felix]

Steps to reproduce:

Created CodePen to demonstrate bug: https://codepen.io/felixhabib/pen/ogjXZKO

Actual results:

For Bottom Value as shown in the rendered example I am getting:

• Firefox: 109.26666259765625
• Chrome: 107.875
• Safari: 107.875

If I tweak certain values such as font the difference between Firefox and others may increase or decrease. It is consistently off

Expected results:

I would expect the value in all browser engines be the same, given no other difference

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Layout: Text and Fonts' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Felix]

Have added h1 padding to override browser styles. new diff values are:

• Firefox: 206.06666564941406
• Chrome: 127.875
• Safari: 127.875

Comment 3

[Felix]

Edit: sometimes Firefox is also showing 129.26666259765625 for the same Codepen

Comment 4

[Emilio Cobos Álvarez (:emilio)]

That seems expected given default fonts are different and so on, or what am I missing? If you use the same font and line-height: 1, I suspect that'd decrease the difference substantially. But also, we use different fixed point units (1/60th of a CSS pixel vs 1/64th) so that can also cause differences with fractional values. I think this is invalid at a glance.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Attachment: Test-case from reporter.

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Locally on Linux if I force font-family: Times; line-height: 1 (the later might not be needed) I get 122.86666870117188 in Firefox, and 122.875 in Chrome.

I think that difference is due to how we represent CSS pixels. our number is ~7372 app units (60th of a CSS pixel), and Chrome's is 7864 of their internal LayoutUnit (64th of a CSS pixel).

We have bug 1719314 open to consider switching to 1/64th of a pixel, but short of doing that (which has different trade-offs, like not being able to represent thirds exactly) this difference is expected.