1459033 - Inconsistent DOM element offsetHeight/scrollHeight reported when Zoomed

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P3)

Description

[javascriptjedi]

Attachment: offsetHeight-bug.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20180322140748

Steps to reproduce:

Background:

We have a widget Framework that manages scrolling of certain elements, handling the display and interaction with scrollbars that we create.  We use the scrollHeight reported by elements in conjunction with the offsetHeight to determine whether overflow has occurred, in which case we need to show scrollbars.

Problem:
When Firefox is zoomed, scrollHeight and offsetHeight are inconsistent with the spec.

Repro:
1. Load the attached sample HTML in Firefox *without* zoom.
2. Click on the div and observe that it reports "204 <=> 204", meaning everything is consistent with the W3C spec. - scrollHeight is 200px, offsetHeight is 204px, and borders occupy 4px.
3. Now load the sample HTML in Firefox with 90% zoom.


Actual results:

4. Click on the div and observe that it reports "204 <=> 202".  This is inconsistent because it means that scrollHeight is 200px, there is 4px of borders, yet the offsetHeight is 202px.  According to the W3C spec that should mean overflow is present, so we show scrollbars - but there is no overflow.


Expected results:

We should see "204 <=> 204" instead, meaning consistent offsetHeight and scrollHeight.

Note that Chrome handles this properly, and always reports "204 <=> 204" regardless of the zoom level.  Further note that Firefox doesn't always "204 <=> 202" - it's dependent upon the zoom.  At 80% zoom, there's no bug.  At 67% zoom, it's reported as "204 <=> 203".  So it's likely a rounding issue inside Firefox.

Comment 1

[Andrew McCreight [:mccr8]]

Kats, is this anything you might know about? Thanks.

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Hm, interesting. I agree with the reporter's assessment that this is probably a result of rounding somewhere in Firefox. However it's not obvious to me that this is fixable without breaking other scenarios. When I load the test page at 90% I can reproduce the 204 <=> 203 alert, but at that zoom when I dump getBoundingClientRect() of the div (which contains the un-rounded values) it shows that the height is 203.30. In Chrome it produces 203.993. Neither of these seem particularly correct to me, but in both cases the integer produced by offsetHeight seems to be the nearest integer. I'm going to redirect this to dbaron since he probably has a better idea of the rounding policy in Gecko and what the expectation here is.

That being said, in Gecko you can also use scrollTopMax > 0 as the check rather than comparing the offsetHeight/scrollHeight and that might give you better results.

Comment 3

[javascriptjedi]

Thanks for looking into it.  I do see the floating point values in getBoundingClientRect() in my repro case div, but note that I only saw integral values for the div in the actual situation where it happens in our widget Framework.  (In that case, the div has several children, which do show fractional values for getBoundingClientRect(), but not the div itself that had the problem with offsetHeight<=>scrollHeight.)  We had the idea of trying to use those values to detect cases where the problem had happened, but because of only seeing integral values, it wasn't a useful approach.

However, I'll look into your suggestion about using scrollTopMax.  That should be better than the workaround we're using now of trying to set scrollTop = 1 and then checking its value to detect whether scrolling is really necessary.