1860479 - Click and Drag Selection Scrolling Slow When Windows Taskbar Hidden

Status: UNCONFIRMED

(Core :: DOM: Selection, defect)

Description

[reyhan.quayum]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/118.0

Steps to reproduce:

On Windows 11 go to Settings -> Taskbar -> Taskbar Behavior, and select "Automatically hide the taskbar"

Then, open any page on Firefox where there is text and the page is vertically scrollable.

Highlight text or elements by holding click and then move the mouse cursor to the bottom of the screen to scroll down while holding the left click button.

A temporary workaround is to use CTRL + F and then do the same, highlighting text and dragging mouse cursor to scroll down.

Actual results:

The page will scroll, albeit at a very slow rate

When using the CTRL + F workaround, the page will scroll at the normal rate expected for click and drag scrolling.

Expected results:

The page should have scrolled at a reasonable rate expected for click and drag scrolling when the Windows taskbar is not hidden. The issue may have something to do with Firefox not thinking the cursor has reached the actual bottom of the window.

Comment 1

[Alice0775 White]

STR:

1. Windows 11 go to Settings -> Taskbar -> Taskbar Behavior, and select "Automatically hide the taskbar"
2. Open Firefox and Maximized
3. Open Webpage e.g. https://ftp.mozilla.org/pub/firefox/nightly/2004/12/
4. Select text by holding click and then move the mouse cursor to the bottom of the screen to scroll down while holding the left click button.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=483ef8bce1e34cd1c40c17818747f7c4f897302b&tochange=9e69ba4a6817636458cd77b59ac8ce7ff0084c74

Comment 2

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

:handyman, since you are the author of the regressor, bug 642851, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 3

[David Parks [:handyman]]

This happens on Windows 10 as well. Although bug 642851 didn't change behavior on other platforms, I don't know if they do what Windows did pre-642851 (using some fallback drag-scroll behavior... see below) or if they do what it does now (using the standard behavior which is said with this bug to be undesirable). It comes down to screen/desktop geometry.

The situation is actually stranger than the report -- the speed adjusts non-monotonically as the cursor approaches the bottom. IOW, moving the cursor 1px up from the bottom of the screen causes it to scroll faster than it does when at the bottom (but still not fast enough).

The cause is two off-by-one errors that work in sync to cause the pre-bug-642851 behavior to use a hacky fallback that works faster/better for the maximized window use case... sometimes. (This behavior also affects windowed drag-scrolling.) This explains strange-but-manageable drag-scrolling I've noticed and subconsciously worked around for years.

Fundamentally, the change introducing this in bug 642851 was the change of the hidden taskbar region from 1px to 2px (kHiddenTaskbarSize). The change accurately reflects Windows geometry. TL;DR: The two off-by-one errors are (1) here, where aViewMax should be considered non-inclusive (coming from visibleRect.YMost()) so the comparison should be <, not <=, and (2) here, where the Most comparisons are again inclusive despite being a test of a rect vs pixel.

For an example, I'll use Y numbers from my 1080p laptop display. What happened at a high level before, when the hidden taskbar region was thought to be 1px, was:

1. User drags to the bottom of the screen. The screen is 1080 pixels high, divided as 85 px for toolbar, 994px content and 1px hidden toolbar. Note that, in the content process, the content region starts at (0,0) so the local mouse Y ranges from 0-993 when over it. Local mouse Y coord when over the 1px hidden taskbar region is 994. So the drag event's mouse Y is 994.
2. The drag causes and AutoScroller to start. It chooses to represent the click as a zero-size rect.
3. That choice, coupled with error (1) above, cause the PresShell not to decide to scroll. It decides that this rect at Y=994 is inside the view whose max is 994, which is wrong. (Consider if the height were 1px, this inclusive comparison would say that a click at 0px and at 1px would be inside, which would make it cover 2px high, not 1px.)
4. So the AutoScroller gets false for didScroll from the PresShell. It then follows the !didScroll part of the link in step 3, which immediately takes it to the bit about "scrolling when directly over something" in error (2) above. It again confuses Y=994 as being within the onePx region because of the incorrect <=. This time the error causes it to engage this fallback, which scrolls 10px each "time".

--

Changing the hidden taskbar size to 2px was just enough to push us out of this behavior and back to the "correct" behavior, where it moves just enough to being the part where we clicked to be onscreen, which is 1px instead of 10px... so much slower.

This wouldn't be hard to "fix" with another hack but it may also be an opportunity to properly correct this, if we have a solution in mind. At least, it is strange that being 0px from the border scrolled 10px at a time but being N>0 px away only scrolls about N px at a time. Maybe it should be 10+N?