Even while dragging the scroll thumb, if the mouse pointer is far enough away from the scrollbar, page scroll position should back to its original position

VERIFIED FIXED in Firefox 65

Status

()

P2
normal
VERIFIED FIXED
27 days ago
6 days ago

People

(Reporter: alice0775, Assigned: kats)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {regression})

64 Branch
mozilla65
x86_64
Windows 10
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox63 wontfix, firefox64 wontfix, firefox65 verified)

Details

Attachments

(2 obsolete attachments)

(Reporter)

Description

27 days ago
Reproducible: always when WebRender is enabled

Steps To Reproduce:
1. Open long page
    --- remember original scroll position
2. Dragging scroll thumb
3. Keeping mouse down, move the mouse pointer away from the scroll bar

Actual results:
Page scroll position does tot back to its original position.

Expected Results:
Page scroll position should back to its original position. This is Windows default behavior.
Strange, this should be handled in the part of the APZ code that is shared between WR and non-WR. I can look into it if it's deemed to be a blocker.

Comment 2

27 days ago
same as bug 1501092?
Duplicate of this bug: 1501092
Yup, thanks.
(Reporter)

Comment 5

26 days ago
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=17a1159f7f4d&tochange=273f8af59697

Regressed by:	43963e011193	Kartikaya Gupta — Bug 1389000 - Turn on webrender layers-free mode by default. r=jrmuizel
Blocks: 1389000
Keywords: regression
No one sets WebRenderLayerScrollData::mVisibleRegion?
(In reply to Botond Ballo [:botond] from comment #6)
> No one sets WebRenderLayerScrollData::mVisibleRegion?

To elaborate on that: triggering the scrollbar sanp-back feature from APZ requires knowing the bounds of the scrollbar thumb node, which comes from ScrollNode::GetVisibleRegion() in APZCTreeManager::UpdateHitTestingTree().

When I fixed bug 1352863, I implemented GetVisibleRegion() for ScrollNode=WebRenderScrollDataWrapper; the value came from WebRenderLayerScrollData::mVisibleRegion which was set in WebRenderLayerScrollData::Initialize(). At the time WebRenderLayerScrollData objects were constructed from layers.

Since then, things were refactored so WebRenderLayerScrollData objects are constructed from display items, and the setting of mVisibleRegion seems to have gotten lost.
https://searchfox.org/mozilla-central/rev/a7f4d3ba4fbfe3efbde832869f1d672fce7122f6/layout/painting/nsDisplayList.cpp#7070

^ This would be the place to re-add the setter, if we can get an equivalent rect from the display item.
Blocks: 1386669
Priority: -- → P2
Assignee: nobody → kats
I have a fix, but I'll try to write a test to go with it.
Created attachment 9020822 [details]
Bug 1501062 - Set the visible region on scrollthumb WebRenderLayerScrollData items. r?botond

This field is used by APZ to implement the feature where the scrollbar snaps
back to the starting position if the mouse gets too far away.
Created attachment 9020843 [details]
Bug 1501062 - Set the visible region on scrollthumb WebRenderLayerScrollData items. r?botond

This field is used by APZ to implement the feature where the scrollbar snaps
back to the starting position if the mouse gets too far away.
Sorry, I tried evolving the changeset via prune -s but I guess phabricator didn't like that...

Updated

20 days ago
Attachment #9020822 - Attachment is obsolete: true

Updated

20 days ago
Attachment #9020843 - Attachment is obsolete: true
Depends on: 1503029

Comment 15

20 days ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/c44da5dca91c
Status: NEW → RESOLVED
Last Resolved: 20 days ago
status-firefox65: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla65
Flags: qe-verify+
Flags: in-testsuite+
status-firefox64: affected → wontfix

Updated

9 days ago
Duplicate of this bug: 1506197

Comment 17

6 days ago
Verified on latest Nightly 65.0a1 with WebRender activated and the issue is fixed, the page scroll position goes back to its original position.
Status: RESOLVED → VERIFIED
status-firefox65: fixed → verified
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.