Closed Bug 1787361 Opened 2 years ago Closed 2 years ago

Dragging scrollbar thumb not working with touchscreen or stylus

Categories

(Core :: Panning and Zooming, defect, P2)

Firefox 104
defect

Tracking

()

VERIFIED FIXED
106 Branch
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)

Attached file regression-log.txt

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.

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/

Summary: Dragging scrollbar thumb not working with touchscreen or styles → Dragging scrollbar thumb not working with touchscreen or stylus

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.

Component: Untriaged → Layout: Scrolling and Overflow
Product: Firefox → Core

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?

Flags: needinfo?(botond)
Keywords: regression
Regressed by: 1753019

[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. :)

Set release status flags based on info from the regressing bug 1753019

Will have a look tomorrow but ni?Dan as well in case he gets to it before me.

Flags: needinfo?(botond) → needinfo?(drobertson)
Flags: needinfo?(botond)

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Status: UNCONFIRMED → NEW
Ever confirmed: true

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.

Flags: needinfo?(fgriffith)

There's too people ni?d, they hopefully get to it soon enough :)

Flags: needinfo?(fgriffith)

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.

(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).

I think I see the issue. I think I created a bug in the way we populate mInScrollbarTouchDrag. Pushed to try here.

Flags: needinfo?(drobertson)

(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.

(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!

Component: Layout: Scrolling and Overflow → Panning and Zooming

Populate hitScrollbarNode after we have cloned the hit test to correctly
determine if we are in a scrollbar touch drag.

Assignee: nobody → drobertson
Status: NEW → ASSIGNED

Thanks Dan for the quick diagnosis and fix!

Flags: needinfo?(botond)
Blocks: 1787560
Severity: -- → S2
Priority: -- → P2

Feels a little weird to set the priority/severity after we have the fix, but I forgot to set it earlier :)

Pushed by drobertson@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/9bde09859e5b
Fix scrollbar touch drag detection when processing touch input. r=botond
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 106 Branch

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 to wontfix.

For more information, please visit auto_nag documentation.

Flags: needinfo?(drobertson)

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

  • 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 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.

Attachment #9291803 - Flags: approval-mozilla-beta?

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)

Flags: qe-verify+

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.

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)]:

relnote-firefox: --- → ?
Target Milestone: 106 Branch → 105 Branch
Target Milestone: 105 Branch → 106 Branch

Added to the Fx105 relnotes. We can move it to 104 if we end up shipping this fix in a dot release, though.

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
Attachment #9291803 - Flags: approval-mozilla-release?

Comment on attachment 9291803 [details]
Bug 1787361 - Fix scrollbar touch drag detection when processing touch input. r=botond

Approved for 104.0.2

Attachment #9291803 - Flags: approval-mozilla-release? → approval-mozilla-release+
QA Whiteboard: [qa-triaged]

Also verified that this is fixed using Firefox 104.0.2 RC, on the same setup (Surface Pro2).

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-triaged]
Flags: qe-verify+

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

(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.

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

Attachment

General

Creator:
Created:
Updated:
Size: