Left/right touchpad scrolling is preempted by forward/back gesture when body is overflow hidden when zoomed in with pref apz.allow_zooming=true
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox73 | --- | verified |
People
(Reporter: tnikkel, Assigned: tnikkel)
References
(Blocks 1 open bug)
Details
Attachments
(2 files, 1 obsolete file)
On mac, Steps to reproduce:
- Enable
apz.allow_zoominginabout:config. - Use the touchpad pinch gesture to zoom in on gmail.com or new reddit.com on a comment page
- Try to scroll the page left or right using the touchpad two-finger gesture.
Actual results:
Firefox goes forward or back in history.
Expected results:
Page should scroll left or right until the edge of the page is reached. At that point, further use of the two-finger left/right gesture should trigger the forward/back action.
In a debug build I hit this assert
which likely explains why this is happening.
|
Assignee | |
Comment 1•5 years ago
|
||
Note that it seems to be hard to get gmail to zoom in, most of the time nothing happens. I usually hit the above assert after some trying, but one time I was able to zoom in and scroll and it caused the history swipe even though I was in the debug build, so somehow I managed to avoid the assert.
|
|
Assignee | |
Comment 2•5 years ago
|
||
Fixing the assert with a patch like this does not fix the bug.
|
|
Assignee | |
Comment 3•5 years ago
|
||
This seems to be a minimal testcase for the reddit problem.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 4•5 years ago
|
||
Oh yes, it's these lines
that are preventing us from getting to the new code.
|
|
Assignee | |
Comment 5•5 years ago
|
||
Doing a rudimentary patch that makes sure we don't consider the scroll frame overflow hidden if we have a visual viewport set and the visual scroll range differs from the scroll range fixes this bug. But that doesn't seem like the right way to detect an overflow hidden scroll frame that is zoomed in so it's actually scrollable.
Botond, do you know what the best way to detect an overflow hidden scroll frame that is zoomed and therefore scrollable on the main thread?
|
||
Comment 6•5 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #5)
Botond, do you know what the best way to detect an overflow hidden scroll frame that is zoomed and therefore scrollable on the main thread?
It sounds like what we want is a "scroll range for user input events", computed as follows:
scrollable rect = overflow:hidden ? layout viewport : scrollable rect
scroll port = have visual viewport ? visual viewport : layout viewport
// compute scroll range based on scrollable rect and scroll port
Note that, in the case of a non-root (no visual viewport) overflow:hidden frame, an empty scroll range naturally falls out of this, since the scrollable rect and the scroll port will both be the layout viewport.
|
|
Assignee | |
Comment 7•5 years ago
|
||
(In reply to Timothy Nikkel (:tnikkel) from comment #0)
In a debug build I hit this assert
which likely explains why this is happening.
This seems to be a separate issue so I moved it to bug 1601527.
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 8•5 years ago
|
||
Previously we were just checking overflow hidden here, which is not enough because we can scroll overflow hidden if we are zoomed in.
Depends on D55917
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
Pushed by tnikkel@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/329340b1608d Add a function that returns if a user can scroll on a given scroll frame in either direction and use it in EventStateManager::ComputeScrollTargetAndMayAdjustWheelEvent. r=botond
|
||
Comment 10•5 years ago
|
||
| bugherder | ||
|
||
Updated•4 years ago
|
|
||
Comment 11•4 years ago
|
||
Confirmed the issue with 73.0a1(2019-12-03) on macOS 10.15.
Fix verified with 74.0a1(2020-01-29) and 73.0b11.
Description
•