1804076 - overlay scrollbar gets hidden behind absolute positioned "headers" element, which overlaps the scrollable area and is sized to the scrollable area's available space

Status: RESOLVED INVALID

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

Description

[bannzor]

Steps to reproduce:

We have an issue where horizontal scrollbars in our grid are unusable in Firefox on Windows 11.

This is due to the overlay scrollbar being hidden behind an absolute positioned element.

I have made a simple sample to demonstrate the issue. Please access this page:
https://yfsbkf.csb.app/

These are the same datagrid, but the first us displaying an aggregate footer row. This row is overlayed on the bottom of the grid. But the horizontal scrollbar is rendering underneath the row. Hence the scrollbar is unusable.

The second grid demonstrates how the scrollbar should appear and function.

Actual results:

When using certain features of our DataGrid, the horizontal scrollbar becomes unusable in Firefox on Windows 11. The scrollbar is rendering beneath a absolute positioned element in our grid.

We have customers filing issues with us due to this rendering bug in FF on Win11. This issue is breaking our customers applications.

Expected results:

The horizontal scrollbar in Firefox on Windows 11 should overlay on top of our aggregate row so it can be scrolled by end users.

Comment 1

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

The severity field is not set for this bug.
:jwatt, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Daniel Holbert [:dholbert]]

I do notice the missing horizontal scrollbar in the top part of your testcase ( https://yfsbkf.csb.app/ ), but that issue doesn't seem to be Firefox-specific -- I get the same issue (covered-up/inaccessible scrollbar) in every browser with overlay scrollbars.

In particular: I see the issue in all of the following browsers-with-overlay-scrollbars:

• Safari, Chrome, and Firefox on macOS (with system configuration "Show scroll bars: when scrolling" i.e. overlay-scrollbars)
• Chrome on Windows/Linux with experimental overlay scrollbars activated in chrome://flags "Overlay Scrollbars" setting.
• Firefox on Windows/Linux with "Always show scrollbars" preference un-checked.

So I think this may be a case where your setup is just incompatible with overlay scrollbars in general, not Firefox's specific implementation of them.

Am I missing something here? If so, could you indicate which other browser you're seeing overlay-scrollbars match your expectation on your https://yfsbkf.csb.app/ demo-app?

Comment 3

[Timothy Nikkel (:tnikkel)]

In general we try not to place overlay scrollbars on top of content that, according to the css model, they do not scroll. Of course the page can adjust and make it seem like that content scrolls with the other scrollable content, so I guess that is what is happening here?

Comment 4

[Botond Ballo [:botond]]

Marking as S3 to get this out of the triage queue while we're waiting for a response to comment 2.

Comment 5

[bannzor]

(In reply to Daniel Holbert [:dholbert] from comment #2)

I do notice the missing horizontal scrollbar in the top part of your testcase ( https://yfsbkf.csb.app/ ), but that issue doesn't seem to be Firefox-specific -- I get the same issue (covered-up/inaccessible scrollbar) in every browser with overlay scrollbars.

In particular: I see the issue in all of the following browsers-with-overlay-scrollbars:

• Safari, Chrome, and Firefox on macOS (with system configuration "Show scroll bars: when scrolling" i.e. overlay-scrollbars)
• Chrome on Windows/Linux with experimental overlay scrollbars activated in chrome://flags "Overlay Scrollbars" setting.
• Firefox on Windows/Linux with "Always show scrollbars" preference un-checked.

So I think this may be a case where your setup is just incompatible with overlay scrollbars in general, not Firefox's specific implementation of them.

Am I missing something here? If so, could you indicate which other browser you're seeing overlay-scrollbars match your expectation on your https://yfsbkf.csb.app/ demo-app?

Hey, sorry for the delay. I did not see a notification about this issue.

Thanks for testing this in other browsers with overlay scrollbars. We did not do that yet. I would say this is a bug in those browsers too. Unless we are to expect overlay-scrollbars to break established behavior in existing web apps.

Unfortunately, our main demo (a very common configuration for our datagrid) is also having very strange scrollbar behavior because of overlay-scrollbars. See: https://www.grapecity.com/wijmo/demos/Grid/Overview/purejs

Personally, I expect new default browser features (like overlay-scrollbar) should not break usability of existing web apps. It's hostile to web developers. I realize our datagrid is very complicated, but its not made in an unreasonable way. The main reason for our scrolling setup is to virtualize DOM of the cells (so the grid can be bound to millions of records, but only render what is within the viewport of the grid's scroll pane).

We really hope you will fix this behavior (not just for our sake).

Also, if there is some clear workaround or solution, please let us know. We want to make sure our product works well in all modern browsers.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to bannzor from comment #5)

Thanks for testing this in other browsers with overlay scrollbars. We did not do that yet. I would say this is a bug in those browsers too. Unless we are to expect overlay-scrollbars to break established behavior in existing web apps.

Thanks. I think overlay scrollbars are the default configuration for all browsers on macOS these days. (Or rather: macOS itself defaults to overlay scrollbars, and all browsers on macOS respect that system setting if it's set.)

Given that this issue affects all browsers with overlay scrollbars, I'm closing it as not-a-Firefox-bug. If this were to be fixed, a fix would probably need to be specced at the standards-body level and implemented interoperably in all browsers; we can't "just" fix this in Firefox.

Unfortunately, our main demo (a very common configuration for our datagrid) is also having very strange scrollbar behavior because of overlay-scrollbars. See: https://www.grapecity.com/wijmo/demos/Grid/Overview/purejs

Yup, I see the same issue there -- the scrollbars are disappearing underneath the headers.

Personally, I expect new default browser features (like overlay-scrollbar) should not break usability of existing web apps. It's hostile to web developers. I realize our datagrid is very complicated, but its not made in an unreasonable way. The main reason for our scrolling setup is to virtualize DOM of the cells (so the grid can be bound to millions of records, but only render what is within the viewport of the grid's scroll pane).

Sure, strong agree. That's a core design principle for new web features. In the (rare) cases where a new feature impacts the default behavior (as is the case with overlay-scrollbars), there may be rough edges, and the folks speccing the feature (standards bodies, generally) will try to resolve those rough edges to minimize impact (but in this case there's clearly some behavior-difference).

The main reason for our scrolling setup is to virtualize DOM of the cells (so the grid can be bound to millions of records, but only render what is within the viewport of the grid's scroll pane).

The virtual DOM is cool, though it's really independent from the issue here. The issue here is that you're superimposing the headers on top of the scrollable area, and expecting it to not cover up the scrollbar. This Just Works with traditional scrollbars because you're doing some extra work to manually size the overlay to be exactly as wide as the available space in the scrollable area, so they don't overlap and so it looks like it's inside of the scroller. But with overlay scrollbars, the available space in the scrollable area includes the scrollbar, so your superimposed headers cover them up, and there's trouble.

Also, if there is some clear workaround or solution, please let us know. We want to make sure our product works well in all modern browsers.

So right now, it looks like your demo is doing the following:
(1) setting up the main (virtualized) content in a scrollable area.
(2) drawing the headers in a second element, outside of the scrollable subtree
(3) superimposing that second element on top of the scrollable element, with an explicit width and overflow: hidden; to clip this superimposed section so that it looks like it's part of the scrolled area (even though it's really an overlay)
(4) and presumably you're determining the explicit-width for that second area based on how wide an element is inside of the first area, or something like that.
(5) and you're manually scrolling that second area by adjusting the position of the headers inside of it, whenever the scrollable area gets scrolled (so that e.g. you can scroll the headers horizontally but not vertically).

This is problematic with overlay scrollbars, since the browser can't tell that you want them to draw on top of the superimposed headers.

To get this to work , I can think of a few options (all of which require a bit of implementation work; sorry I don't have an easy one-liner to suggest)
(1) Most graceful solution: make the headers position:sticky and put them inside of the scrollable area (taking care not to replace their contents when you do your virtualized-DOM stuff). Then, they'll just scroll automatically with the scrollable area (while sticking in the axis that you want them to stick). Toy example of how that looks (with just a sticky header in a scrollable area) https://jsfiddle.net/dholbert/a1ywmLub/
(2) Slightly less graceful but possibly less redesign effort: you could just move the scrollable area such that it's not covered up by your headers at all. i.e. shift it down-and-to-the-right, and get rid of whatever space you're reserving for the headers there. This might be slightly awkward since you're still keying off of the scrollbars to dynamically scroll the headers, though.
(3) Maybe there's a way to just disable overlay scrollbars and force traditional scrollbars in CSS? I sort of thought there was but I couldn't find one. If there is, though, then maybe you just want to do that.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #6)

(3) Maybe there's a way to just disable overlay scrollbars and force traditional scrollbars in CSS? I sort of thought there was but I couldn't find one. If there is, though, then maybe you just want to do that.

(Update on this^: I double-checked with some other csswg folks -- and it looks like there intentionally isn't a way for websites to force traditional scrollbars; the idea is that they're a user preference, and browsers should respect the user's preference.)

Really, I think the most robust/graceful recommendation is to use position:sticky on the header elements, and structure them as DOM children of the scrollable area -- it's a way to more-directly achieve the effect that you're achieving with the abspos overlay right now, and it does so in a way where the browser can tell that the header is part of the scrolled content rather than something intentionally-covering-up the scrolled content.

Comment 8

[bannzor]

(In reply to Daniel Holbert [:dholbert] from comment #7)

(In reply to Daniel Holbert [:dholbert] from comment #6)

(3) Maybe there's a way to just disable overlay scrollbars and force traditional scrollbars in CSS? I sort of thought there was but I couldn't find one. If there is, though, then maybe you just want to do that.

(Update on this^: I double-checked with some other csswg folks -- and it looks like there intentionally isn't a way for websites to force traditional scrollbars; the idea is that they're a user preference, and browsers should respect the user's preference.)

Really, I think the most robust/graceful recommendation is to use position:sticky on the header elements, and structure them as DOM children of the scrollable area -- it's a way to more-directly achieve the effect that you're achieving with the abspos overlay right now, and it does so in a way where the browser can tell that the header is part of the scrolled content rather than something intentionally-covering-up the scrolled content.

Hey Daniel, thanks for the detailed explanation. I understand your position/decision, but still think this feature is antithetical to the goal of web compatibility. I suppose its a rare case in general, but we have thousands of customers with millions of end users, including huge companies. So while we are just one company, our tools are used widely. Because we support large companies, we also strive for compatibility. The reason we setup the virtual scroll this way (with overlays instead of position sticky) is that we supported IE for many of our biggest customers. IE is EoL so its we have stopped making decisions like this to support it. But as you pointed out, it is a big change. Our product is also very extensible, in fact some customers completely take over rendering. So this will cause them to refactor as well.

In short, I get it, but I still think its bad pattern for modern browsers to follow. But its clearly a trend and we will need to adapt.

Thanks again for your help.