Dragging scrollbar thumb not working with touchscreen or stylus
Categories
(Core :: Panning and Zooming, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
relnote-firefox | --- | 104+ |
firefox-esr91 | --- | unaffected |
firefox-esr102 | --- | unaffected |
firefox104 | + | verified |
firefox105 | --- | verified |
firefox106 | --- | verified |
People
(Reporter: shd, Assigned: dlrobertson)
References
(Regression)
Details
(Keywords: regression)
Attachments
(3 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:104.0) Gecko/20100101 Firefox/104.0
Firefox for Android
Steps to reproduce:
On my Surface Pro tablet, I tried to drag the scrollbar thumb up/down with my finger on the touchscreen or with the stylus.
Actual results:
The page scrolled as if my finger (or stylus) was in the main content, in the opposite direction to the way dragging the scrollbar thumb should work.
Expected results:
The scrollbar thumb should have followed my touch / stylus, scrolling the page accordingly.
Reporter | ||
Comment 1•2 years ago
|
||
Extra info: tapping my finger/stylus in the scrollbar track does make the thumb jump to the appropriate location. Using a mouse or touchpad (rather than touchscreen) also works normally.
On Reddit, other users have confirmed the problem and I was asked to do a regression test (see log file in the attachment of the initial bug description, narrowing it down to a single commit). Link to the Reddit thread for completeness: https://www.reddit.com/r/firefox/comments/wwkz98/scrollbar_not_working_with_touch_or_stylus/
Reporter | ||
Updated•2 years ago
|
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Layout: Scrolling and Overflow' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 3•2 years ago
|
||
Botond, I can reproduce this issue on my personal device, and from what Steven found in his mozregression run, patch D150047 of bug 1753019 is the regressor. Could you have a look?
Comment 4•2 years ago
|
||
[Tracking Requested - why for this release]:
This is making it impossible to use touch or stylus input to drag the scrollbar (at least on Windows, I don't have any other platform to test right now). Since scrolling the page by "dragging" the content works fine, and I assume that only a small number of users will actually try to use the scrollbar itself on touchscreen or stylus input, this is more an RelMan-FYI-ping. :)
Comment 5•2 years ago
|
||
Set release status flags based on info from the regressing bug 1753019
Comment 6•2 years ago
|
||
Will have a look tomorrow but ni?Dan as well in case he gets to it before me.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Comment 8•2 years ago
|
||
The bug is marked as tracked for firefox104 (release). However, the bug still isn't assigned.
:fgriffith, could you please find an assignee for this tracked bug? Given that it is a regression and we know the cause, we could also simply backout the regressor. If you disagree with the tracking decision, please talk with the release managers.
For more information, please visit auto_nag documentation.
Comment 9•2 years ago
|
||
There's too people ni?d, they hopefully get to it soon enough :)
Assignee | ||
Comment 10•2 years ago
|
||
I don't have a device to test this on, but I find it surprising that D150047 is the patch that regresses this. Most of the code there should only impact Android. D148648 of the two patches in bug 1753019 was the patch I originally suspected. This patch did change some conditions that relied on HasDynamicToolbar
and also adds another HTTN to the hit test result. This makes me wonder if I messed up something in the hit test result with the scrollbar node. Which might indicate that bug 1778007 could fix the issue. I'll continue to debug this today.
Comment 11•2 years ago
|
||
(In reply to Dan Robertson (:dlrobertson) from comment #10)
I don't have a device to test this on, but I find it surprising that D150047 is the patch that regresses this. Most of the code there should only impact Android. D148648 of the two patches in bug 1753019 was the patch I originally suspected.
The mozregression output in the log in comment 0 is a bit misleading; it did not in fact narrow it down to a single commit, just to a single autoland push, which contains both D148648 and D150047. So the actual regressor may well be D148648 (and I agree that's more likely).
Assignee | ||
Comment 12•2 years ago
|
||
I think I see the issue. I think I created a bug in the way we populate mInScrollbarTouchDrag
. Pushed to try here.
Comment 13•2 years ago
|
||
(In reply to Dan Robertson (:dlrobertson) from comment #12)
Pushed to try here.
Thanks for the try push! I tested the win64/opt build, and on my Surface 7, I can use the scrollbar with both my finger and the stylus again.
Assignee | ||
Comment 14•2 years ago
|
||
(In reply to Dennis Schubert [:denschub] from comment #13)
Thanks for the try push! I tested the win64/opt build, and on my Surface 7, I can use the scrollbar with both my finger and the stylus again.
Thanks for testing!
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 15•2 years ago
|
||
Populate hitScrollbarNode after we have cloned the hit test to correctly
determine if we are in a scrollbar touch drag.
Updated•2 years ago
|
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 17•2 years ago
|
||
Feels a little weird to set the priority/severity after we have the fix, but I forgot to set it earlier :)
Comment 18•2 years ago
|
||
Comment 19•2 years ago
|
||
bugherder |
Comment 20•2 years ago
|
||
bugherder |
Comment 22•2 years ago
|
||
The patch landed in nightly and beta is affected.
:dlrobertson, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox105
towontfix
.
For more information, please visit auto_nag documentation.
Comment hidden (obsolete) |
Assignee | ||
Comment 24•2 years ago
|
||
Populate hitScrollbarNode after we have cloned the hit test to correctly
determine if we are in a scrollbar touch drag.
Original Revision: https://phabricator.services.mozilla.com/D155733
Comment 25•2 years ago
|
||
- User impact if declined Without this patch users may be unable to use touch or stylus gestures to scroll (see bug 1787361(comment 4) for more details).
- Code covered by automated testing no
- Fix verified in Nightly yes
- Needs manual QE test no
- Steps to reproduce for manual QE testing N/A
- Risk associated with taking this patch Low
- Explanation of risk level Simple change that reverts scrollbar hit handling to previous behavior.
- String changes made/needed No
- Is Android affected? no
Comment 26•2 years ago
|
||
Comment on attachment 9291803 [details]
Bug 1787361 - Fix scrollbar touch drag detection when processing touch input. r=botond
Clearing this request since Dan was kind enough to test out the moz-phab uplift process instead.
Comment 27•2 years ago
•
|
||
bugherder uplift |
Landed for 105.0b5.
https://hg.mozilla.org/releases/mozilla-beta/rev/807a56e29a27
Comment 28•2 years ago
|
||
A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)
Updated•2 years ago
|
Comment 29•2 years ago
|
||
Reproduced the initial issue using an old Nightly from 2022-08-25 on Windows 10 (Surface Pro2), verified that using latest Nightly 106.0a1 and Latest Firefox beta 105.0b5, I can now scroll on the page using the thumb and stylus by grabbing the scroll elevator.
Comment 31•2 years ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: Dragging scrollbar thumbnail was not working with touchscreen or stylus. This has been fixed in x105.
[Affects Firefox for Android]:N
[Suggested wording]: Dragging scrollbar thumbnail was not working with touchscreen or stylus. This has been fixed in x105.
[Links (documentation, blog post, etc)]:
Updated•2 years ago
|
Comment 32•2 years ago
|
||
Added to the Fx105 relnotes. We can move it to 104 if we end up shipping this fix in a dot release, though.
Assignee | ||
Comment 33•2 years ago
|
||
Comment on attachment 9291803 [details]
Bug 1787361 - Fix scrollbar touch drag detection when processing touch input. r=botond
Beta/Release Uplift Approval Request
- User impact if declined: Without this patch users may be unable to use touch or stylus gestures to scroll (see bug 1787361(comment 4) for more details).
- Is this code covered by automated tests?: No
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Simple change that reverts scrollbar hit handling to previous behavior.
- String changes made/needed:
- Is Android affected?: No
Comment 34•2 years ago
|
||
Comment on attachment 9291803 [details]
Bug 1787361 - Fix scrollbar touch drag detection when processing touch input. r=botond
Approved for 104.0.2
Comment 35•2 years ago
|
||
bugherder uplift |
Updated•2 years ago
|
Comment 37•2 years ago
|
||
Also verified that this is fixed using Firefox 104.0.2 RC, on the same setup (Surface Pro2).
Updated•2 years ago
|
Comment 38•2 years ago
|
||
could this be related to #1530605 ? where Devtools Panels are almost all broken when using a pen tablet.
Just checked with Nightly 106 on Win10
Comment 39•2 years ago
|
||
(In reply to serradeil from comment #38)
could this be related to #1530605 ? where Devtools Panels are almost all broken when using a pen tablet.
Just checked with Nightly 106 on Win10
Not related, this bug is a recent regression which has been fixed, that one is a long-standing issue.
Description
•