1753146 - Decrease swipe-to-nav sensitivity on Windows

Status: VERIFIED FIXED

(Core :: Widget: Win32, defect, P2)

Description

[Hiroyuki Ikezoe (:hiro)]

+++ This bug was initially created as a clone of Bug #1751124 +++

Though I have totally no idea why the swipe-to-nav arrow didn't show in the bug 1751124 reporter's environment, Timothy noticed that on Windows swipe-to-nav is twice sensitive as Chrome/Edge does. So in this bug we are going to tweak the sensitivity to see if it will fix/mitigate bug 1751124 case.

Comment 1

[Hiroyuki Ikezoe (:hiro)]

Dustin, would you mind trying a new build with tweaking some preference values to see if it mitigates the issue you are in trouble?

You can download the build from here;
https://treeherder.mozilla.org/jobs?repo=try&revision=8170e957eb982111cf53e86352941b4e96da41e4&selectedTaskRun=Uwqb-2rJRxKugw01BRJqWw.0

Click "Artifacts and Debugging Tools" in the right bottom pane and target.zip is the build; here is the direct link to the target.zip

The prefs you will have to tweak are;

1. widget.disable-swipe-tracker: false <- this is mandatory
2. widget.swipe.success-threshold
3. widget.swipe.success-velocity-contribution

I think the second pref is you'll have to tweak, the default value is 0.25, with 0.5 on my Windows laptop, swipe-to-nav sometimes didn't happen when I want to navigate.

Thanks!

Comment 2

[Hiroyuki Ikezoe (:hiro)]

Note that the build doesn't solve non visual affordance issue since I have no idea how the issue case happens.

Comment 3

[Timothy Nikkel (:tnikkel)]

I just did a comparison of Firefox/Chrome/Edge on Windows, and Chrome/Safari/Firefox on mac. On mac it is quite sensitive in all 3 apps. On Windows Chrome and Edge are much less sensitive. So it makes sense that it would be too sensitive on Windows if we used the same parameters as mac.

Comment 4

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

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

Comment 5

[Dustin L. Howett]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #1)

Dustin, would you mind trying a new build with tweaking some preference values to see if it mitigates the issue you are in trouble?

I think the second pref is you'll have to tweak, the default value is 0.25, with 0.5 on my Windows laptop, swipe-to-nav sometimes didn't happen when I want to navigate.

Thanks!

Thanks for the build! It still feels pretty sensitive to me, even at success-threshold 1.0. I feel like every time I scroll something to the side too aggressively, I'm navigating. Maybe I'm being aggressive, but it happens most when I am trying to scroll a horizontal scrolling region all the way to the left and I give it a solid flick.

Funny enough, I do have a visual affordance with this build.

Shouldn't swipe navigation only apply when there was nothing else to scroll? Just like "pull to refresh" doesn't trigger unless you're at or above the actual top of a page on platforms that support it.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

(In reply to Dustin L. Howett from comment #5)

Thanks for the build! It still feels pretty sensitive to me, even at success-threshold 1.0. I feel like every time I scroll something to the side too aggressively, I'm navigating. Maybe I'm being aggressive, but it happens most when I am trying to scroll a horizontal scrolling region all the way to the left and I give it a solid flick.

Funny enough, I do have a visual affordance with this build.

Good to hear to see the arrow.

Shouldn't swipe navigation only apply when there was nothing else to scroll? Just like "pull to refresh" doesn't trigger unless you're at or above the actual top of a page on platforms that support it.

swipe-to-nav should happen at the edge of the root scroller. So you meant the arrow appears even if the scroll position of the root content is not at the left/right edge? That's odd. Can you please give us your device name? Though I am unsure the device is related to or not.

Comment 7

[Botond Ballo [:botond]]

I think a specific example URL with horizontally scrollable content would also be helpful.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1753146 - Drop unused kRubberBandResistanceFactor. r?tnikkel

Comment 9

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1753146 - Add preferences for tweaking swipe gestures. r?tnikkel

Depends on D138236

Comment 10

[Hiroyuki Ikezoe (:hiro)]

I realized that there's a copy-and-paste error in the build in comment 7.

here is a new build fixing the error.

Comment 11

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

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

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Now the original reporter's case has been fixed by bug 1754674 (see bug 1751124 comment 25). Let's land these changes.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #12)

Now the original reporter's case has been fixed by bug 1754674 (see bug 1751124 comment 25). Let's land these changes.

I was wrong. That's not the issue originally reported in bug 1751124.

Comment 14

[Dustin L. Howett]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #13)

I can no longer reproduce the issue where swipe-to-navigate is activated when I have extra "inertia" while scrolling in a horizontal container, as of 99.0a1 (2022-02-13).

The visuals only appear when the window is narrow; this may be useful information for that bug. :)

Comment 15

[Hiroyuki Ikezoe (:hiro)]

(In reply to Dustin L. Howett from comment #14)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #13)

I can no longer reproduce the issue where swipe-to-navigate is activated when I have extra "inertia" while scrolling in a horizontal container, as of 99.0a1 (2022-02-13).

Okay, that's probably fixed by bug 1754674.

The visuals only appear when the window is narrow; this may be useful information for that bug. :)

How wide is your browser window? On my windows laptop the screen width is 2560px, I tried with 1.0 DPI, thus I believe the browser window size is also 2560px, but I can see the arrows.

Comment 16

[Dustin L. Howett]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #15)

The visuals only appear when the window is narrow; this may be useful information for that bug. :)

How wide is your browser window? On my windows laptop the screen width is 2560px, I tried with 1.0 DPI, thus I believe the browser window size is also 2560px, but I can see the arrows.

That was likely a red herring. My main browser window would not display the visuals, but all new browser windows in the same session would. I can no longer reproduce that, and all windows display the visual after a restart.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9a1278927517
Drop unused kRubberBandResistanceFactor. r=tnikkel
https://hg.mozilla.org/integration/autoland/rev/74fbc27b1862
Add preferences for tweaking swipe gestures. r=tnikkel

Comment 18

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/9a1278927517
https://hg.mozilla.org/mozilla-central/rev/74fbc27b1862

Comment 19

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

The patch landed in nightly and beta is affected.
:hiro, is this bug important enough to require an uplift?
If not please set status_beta to wontfix.
If yes, don't forget to request an uplift for the patches in the regression caused by this fix.

For more information, please visit auto_nag documentation.

Comment 20

[Timothy Nikkel (:tnikkel)]

Regressed by bug 1348786 but disabled on 97 and 98 in bug 1751124 so updating flags.

Comment 21

[Ardelean Oana, Desktop Test Engineering [:oardelean]]

Reproducible on Nightly 98.0a1(20220201213236) on Win10 64-bits. Confirmed as fixed on Firefox 99.0(20220330194208) and Nightly 100.0a1(20220403215202) on Win10 64-bits.