Closed Bug 1365806 Opened 6 years ago Closed 3 years ago

empty element has an offsetheight if given overflow-y:scroll, unlike other browsers


(Core :: Layout: Scrolling and Overflow, defect, P3)




Webcompat Priority P3
Tracking Status
firefox66 --- wontfix
firefox78 --- fixed


(Reporter: wisniewskit, Assigned: emilio)


(Regressed 1 open bug, )


(Keywords: polish, testcase, Whiteboard: [webcompat][tpi:+], [wptsync upstream])


(2 files)

Attached file testcase.html
As per the attached testcase, giving an otherwise-empty element overflow-y:scroll will forcefully give it an offsetHeight (the actual value varies from theme to theme).

Other browsers all give the element a zero offsetHeight (I have tested Chrome, Safari, Edge, and Internet Explorer 11).

This currently affects the UK Labor Party's website, as it expects the offsetHeight of such an element to be === 0, and otherwise leaves its height alone, making a section of the site's content appear much smaller than it otherwise would be (as shown in the related issue #6353).
I'm guessing that's because we impose a minimum size on the scrollbar,
and other UAs don't?
data:text/html,<div style="overflow-y:scroll; border:1px solid"></div>

I think that comes from the Widget layer, e.g.:
Component: DOM → Widget
Keywords: testcase
Keywords: polish
Priority: -- → P3
Whiteboard: [webcompat] → [webcompat][tpi:+]
Yes, this seems to be the culprit. When I remove that switch-case, the rendering is similar to other browsers. But I'm not sure if the problem in bug 513006 that case fixed is still a concern. Thoughts?
Flags: needinfo?(mats)
Flags: webcompat?
In Chrome the box is      0px high 
and in Firefox, this is  16px high
data:text/html,<div style="height:auto;overflow-y:scroll;background-color:pink"></div>

Visible on Rakuten on Android

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Webcompat Priority: --- → ?

See bug 1547409. Migrating whiteboard priority tags to program flags.

Webcompat Priority: ? → P3

To add, this is causing issues on with a persistent bar floating on screen. (Although they should be using overflow: auto there instead)
Comparison between Firefox and Chrome behavior:

Fwiw, this is the widget-imposed min size of the scrollbar element.

Should we change that imposition?

Probably... I can look into it, just not right now.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)
Assignee: nobody → emilio

Also, don't suppress scrollbars if the scrollport is less than their
width, as that can happen now :)

Scrollbars code is tricky, so I'll wait until the soft freeze is over to
land this.

Component: Widget → Layout: Tables
Component: Layout: Tables → Layout: Scrolling and Overflow
Attachment #9144917 - Attachment description: Bug 1365806 - Make scrollbars not impose a minimum size. r=dholbert → Bug 1365806 - Make scrollbars not impose a minimum size on the scroller. r=dholbert
Pushed by
Make scrollbars not impose a minimum size on the scroller. r=dholbert
Pushed by
Make scrollbars not impose a minimum size on the scroller. r=dholbert
Created web-platform-tests PR for changes under testing/web-platform/tests
Whiteboard: [webcompat][tpi:+] → [webcompat][tpi:+], [wptsync upstream]
Flags: needinfo?(mats)
Flags: needinfo?(emilio)
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla78
Upstream PR merged by moz-wptsync-bot
Regressions: 1637511
Regressions: 1667929
You need to log in before you can comment on or make changes to this bug.