Open Bug 1786016 Opened 2 years ago Updated 10 months ago

Cannot detect overlay/hiding scrollbars [regression]

Categories

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

Product:
Core
Component:
Layout: Scrolling and Overflow
Version:
Firefox 102
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: ossman, Unassigned)

Details

Attachments

(1 file)

Test case
951 bytes, text/html
Details
Attached file Test case —

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

Detect if the browser has useful scrollbars by creating an element with "overflow = scroll" and measure the size of the scrollbars.

Actual results:

The returned size is 0.

Expected results:

Previously, the returned size was non-zero. That is probably incorrect given the current behaviour. But we need some other way to detect useful scrollbars to determine if fallback behaviours should be enabled.

The reason we need this is that we grab clicks and scroll events, so other scrolling methods do not work. So, we need to determine if it is possible for the user to still grab the scroll bars, or if we need to fall back to a click-and-drag behaviour for the scrolling.

This is used in noVNC when the remote session is larger than what fits in the browser window.

To make things extra complex, we ideally need to be able to tell the difference between the macOS way of hiding scrollbars, and the Linux/Windows way. The key difference between them being if mouse movement makes the scrollbar reappear.

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

Component: Untriaged → Panning and Zooming
Product: Firefox → Core
Flags: needinfo?(emilio)

What do you mean with "useful scrollbars"? When does a browser not have useful scrollbars? Your test-case seems to detect overlay / non-overlay scrollbars correctly here on Linux (if I go to settings and check "always show scrollbars" it returns "yes", otherwise "no"). But that's been the behavior for macOS for a long long while.

Flags: needinfo?(emilio) → needinfo?(ossman)

The default scrollbar behavior changed on Linux in bug 1147847, but as I said your script seems to detect those?

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

What do you mean with "useful scrollbars"? When does a browser not have useful scrollbars?

Historically, on mobile devices where the scrollbars aren't shown at all. Not even overlays. That's the scenario our code was originally written for. Today, some overlay scrollbars are always useful, but some are only useful under certain circumstances.

Again, this is a problem that is specific to the case where mouse interaction with the page content is caught. A "normal" web page will not have this issue.

Basically, there are usually a couple of ways a user can scroll a page:

  • Scroll wheel
  • Touch and drag
  • Keyboard (up/down, page up/page down, etc.)
  • Clicking the scollbar

The first three are grabbed by our page content, since those events are expected to interact with the application. So, that leaves the scrollbar as the only way the user can actually scroll.

Unfortunately, some browsers will not always provide a scrollbar that works. Which is what we need to detect, so we can hobble the application a bit to provide some scroll ability to the user.

The first such scenario were mobile devices, where there is no scrollbar. So that was easy enough to detect.

The second scenario was macOS, which uses an overlay with the very odd behaviour that it doesn't show up until something else scrolls the page. So, it is effectively useless by itself.

The problem is now that Firefox has introduced an overlay scrollbar that actually still works, since it reappears once you move the mouse around. We want to support that scrollbar and not have to hobble noVNC, thinking that there aren't any functional scrollbars.

Your test-case seems to detect overlay / non-overlay scrollbars correctly here on Linux (if I go to settings and check "always show scrollbars" it returns "yes", otherwise "no").

Correct. But the goal of the test is not to detect overlay / non-overlay. It is to detect functional (rather than missing / useless) scrollbars. Which is where checking for size is no longer a good approximation. We basically want some new API (or heuristic until then).

But that's been the behavior for macOS for a long long while.

On that note, they seem to have changed that. On macOS 12 I get scrollbars again. Looking at the settings, it seems to depend on if the system thinks it has a mouse connected.

Flags: needinfo?(ossman)

Unfortunately, some browsers will not always provide a scrollbar that works. Which is what we need to detect, so we can hobble the application a bit to provide some scroll ability to the user.

What browsers are these? You mean mobile browsers where you can't drag-and-move the scrollbar?

That seems like a browser bug tbh. Adding APIs to workaround other browsers' bugs doesn't seem very appealing :/

Correct. But the goal of the test is not to detect overlay / non-overlay. It is to detect functional (rather than missing / useless) scrollbars. Which is where checking for size is no longer a good approximation. We basically want some new API (or heuristic until then).

What would be the heuristic / what would the API do? We always have some sort of usable scrollbars, otherwise it's a bug that we should fix.

On that note, they seem to have changed that. On macOS 12 I get scrollbars again. Looking at the settings, it seems to depend on if the system thinks it has a mouse connected.

That depends on the macOS system settings. We've respected that setting since forever, and it seems like the test has been broken since forever...

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

Correct. But the goal of the test is not to detect overlay / non-overlay. It is to detect functional (rather than missing / useless) scrollbars. Which is where checking for size is no longer a good approximation. We basically want some new API (or heuristic until then).

What would be the heuristic / what would the API do? We always have some sort of usable scrollbars, otherwise it's a bug that we should fix.

If I'm understanding correctly, the desire is to detect if the scrollbars are "usable enough to be the only way to scroll the page". Mac overlay scrollbars do not meet this criterion because you need to start scrolling the page by some other means to get them to show, but Linux overlay scrollbars do because you just need to move the mouse to get them to show.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #7)

Unfortunately, some browsers will not always provide a scrollbar that works. Which is what we need to detect, so we can hobble the application a bit to provide some scroll ability to the user.

What browsers are these? You mean mobile browsers where you can't drag-and-move the scrollbar?

That seems like a browser bug tbh. Adding APIs to workaround other browsers' bugs doesn't seem very appealing :/

Both Firefox and Chrome has this behaviour on Android. So bug or not, it seems to be the current de-facto standard, and hence something we just need to adapt to as application developers. :/

What would be the heuristic / what would the API do? We always have some sort of usable scrollbars, otherwise it's a bug that we should fix.

We would like something like document.hasScrollbars. Or perhaps matchMedia("scrollbars") is more appropriate.

This should return true for scrollbars the user can interact with, but false for purely cosmetic ones. So, Firefox Android would return false, and Firefox Desktop would return true, no matter if the scrollbar is an overlay or has a proper gutter.

The question is what to do until such a thing is in place. I'm hoping we can avoid user agent matching.

That depends on the macOS system settings. We've respected that setting since forever, and it seems like the test has been broken since forever...

The test has actually given desirable results on macOS, as it has its wonky behaviour in overlay mode.

(In reply to Botond Ballo [:botond] from comment #8)

If I'm understanding correctly, the desire is to detect if the scrollbars are "usable enough to be the only way to scroll the page". Mac overlay scrollbars do not meet this criterion because you need to start scrolling the page by some other means to get them to show, but Linux overlay scrollbars do because you just need to move the mouse to get them to show.

Precisely. But in the principle of practicality, I could live with having to special case macOS because of its rather odd behaviour. But I would like something that functionally detects the difference between Firefox Android and Firefox Linux.

Another workaround would be if it is possible to force Firefox to show gutters, even on platforms where overlay is the default. Can you do that via CSS somehow? Chrome seems to have some functionality as that happens when you visit their web store.

(In reply to Pierre Ossman from comment #9)

(In reply to Botond Ballo [:botond] from comment #8)

If I'm understanding correctly, the desire is to detect if the scrollbars are "usable enough to be the only way to scroll the page". Mac overlay scrollbars do not meet this criterion because you need to start scrolling the page by some other means to get them to show, but Linux overlay scrollbars do because you just need to move the mouse to get them to show.

Precisely. But in the principle of practicality, I could live with having to special case macOS because of its rather odd behaviour. But I would like something that functionally detects the difference between Firefox Android and Firefox Linux.

But that's not true if you don't have a pointing device for example, right? Then you'd be able to scroll with the keyboard, but the scrollbar would still be "not useful".

I'm still confused as to what exactly you're doing that requires branching on this, but it seems per your comments that this should be discussed in the CSS Working Group. Consider filing an issue in https://github.com/w3c/csswg-drafts/issues/new? Happy to put it on the agenda.

(In reply to Pierre Ossman from comment #10)

Another workaround would be if it is possible to force Firefox to show gutters, even on platforms where overlay is the default. Can you do that via CSS somehow? Chrome seems to have some functionality as that happens when you visit their web store.

We support the scrollbar-gutter property (https://andreubotella.com/csswg-auto-build/css-overflow-3/#scrollbar-gutter-property) but that doesn't do anything with overlay scrollbars.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

(In reply to Pierre Ossman from comment #9)
I'm still confused as to what exactly you're doing that requires branching on this

I understood it to be the use case described in comment 1:

The reason we need this is that we grab clicks and scroll events, so other scrolling methods do not work. So, we need to determine if it is possible for the user to still grab the scroll bars, or if we need to fall back to a click-and-drag behaviour for the scrolling.

This is used in noVNC when the remote session is larger than what fits in the browser window.

(In reply to Pierre Ossman from comment #9)

in the principle of practicality, I could live with having to special case macOS because of its rather odd behaviour. But I would like something that functionally detects the difference between Firefox Android and Firefox Linux.

Isn't a check for being on mobile sufficient here? i.e. do you ever not want to support touch-drag-to-scroll on mobile?

(needinfo for the question in the previous comment)

Will meanwhile mark this as S3 for now to get this out of the triage queue.

Severity: -- → S3
Component: Panning and Zooming → Layout: Scrolling and Overflow
Flags: needinfo?(ossman)
Priority: -- → P3

(In reply to Emilio Cobos Álvarez (:emilio) from comment #11)

I'm still confused as to what exactly you're doing that requires branching on this, but it seems per your comments that this should be discussed in the CSS Working Group. Consider filing an issue in https://github.com/w3c/csswg-drafts/issues/new? Happy to put it on the agenda.

Filed here: https://github.com/w3c/csswg-drafts/issues/7697

(In reply to Botond Ballo [:botond] from comment #12)

Isn't a check for being on mobile sufficient here? i.e. do you ever not want to support touch-drag-to-scroll on mobile?

Possibly. But is there a clean way to do so? E.g. touch isn't exclusive to mobile devices.

We want the check to be as close as possible to what we really want to know, or we run the risk of false positives or false negatives (as we've seen with the current code).

Flags: needinfo?(ossman)

(In reply to Pierre Ossman from comment #14)

Isn't a check for being on mobile sufficient here? i.e. do you ever not want to support touch-drag-to-scroll on mobile?

Possibly. But is there a clean way to do so? E.g. touch isn't exclusive to mobile devices.

Based on https://developer.mozilla.org/en-US/docs/Web/HTTP/Browser_detection_using_the_user_agent#mobile_tablet_or_desktop, one approach could be to check for the presence of Mobile in the user agent string.

Regardless of the "useful scrollbars" and etc discussion, as the description states: trying to measure scrollbars with overflow: scroll fails. Because the scrollbars are not displayed - FF effectively treats it as overflow: auto.

To reproduce Just add:

<div style="display:block;position:absolute;width:200px;height:200px;overflow:scroll;left:0;top:0px;background-color:bisque">
</div>

That doesn't seem valid according to https://developer.mozilla.org/en-US/docs/Web/CSS/overflow#syntax or https://www.w3.org/TR/css-overflow-3/#propdef-overflow

That's with Firefox 124.0.2 (64 bit) on Windows 11.
userAgent=Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:124.0) Gecko/20100101 Firefox/124.0

trying to measure scrollbars with overflow: scroll fails. Because the scrollbars are not displayed

OK, no: div.offsetWidth - div.clientWidth equals 0 even if you do force overflow. Right, because the scrollbars are overlays. Nevermind, this is a separate thing - registered https://bugzilla.mozilla.org/show_bug.cgi?id=1890751

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: