1666095 - alt+wheel mouse move in history and conflict with XFCE accessibility

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Popolon]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:80.0) Gecko/20100101 Firefox/80.0

Steps to reproduce:

In a firefox beta 80, window, and I stroke alt+mouse wheel.

Actual results:

The current page is moving very fast in the history (and an unusable way), that was not the case in previous version, conflicting with accessibilty

Expected results:

Nothing, this conflict with alt + wheel mouse accessibility zoom in XFCE window manager.

Comment 1

[Popolon]

Sorry this bug is in firefox 81 beta, not 80 (stable I use here).

Comment 2

[Alice0775 White]

I can reproduce the issue on Nightly83.0a1 Windows10.

Steps to reproduce:

1. Open new tab
2. visit https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions from address bar
3. visit https://ftp.mozilla.org/pub/firefox/nightly/ from address bar
4. visit https://en.wikipedia.org/wiki/Wikipedia from address bar
5. Alt+mouse wheel down / up

Actual results:
The tab history of step 2,3 are skipped

Expected results:
The tab history should be back and forward in sequence.

Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=87ad6cc2ae3f5af22335f8a1c3213a14f990fc50&tochange=891bf9d395fd25e5dee20f67278a591d7dd47e84

Comment 3

[Johann Hofmann [:johannh]]

That's strange because browser.navigation.requireUserInteraction is set to false at the moment. So entries shouldn't be skipped. What's the value of that pref for you?

If it's true then it's a dupe of bug 1644914.

Comment 4

[Alice0775 White]

The bad build(79.0a1) of the regression window:
browser.navigation.requireUserInteraction=true

82.0b8 and 83.0a3(reproducible the issue):
browser.navigation.requireUserInteraction=false

Comment 5

[Johann Hofmann [:johannh]]

Ok, thanks, I'll take a look.

Comment 6

[Chris Peterson [:cpeterson]]

Severity N/A because this bug doesn't currently affect users because requireUserInteraction is off by default.

block requireUserInteraction meta bug 1645211

Comment 7

[Johann Hofmann [:johannh]]

This is incorrect, the pref doesn't seem to matter here according to comment 4.

Comment 8

[Popolon]

Personaly I had this only on 81 beta, not in 80 stable, 81 stable and 82 beta is not affected either.

Comment 9

[Johann Hofmann [:johannh]]

Can you confirm that this is caused by flipping the browser.navigation.requireUserInteraction to true? Thanks!

Comment 10

[Alice0775 White]

The problem is
https://searchfox.org/mozilla-central/source/dom/events/EventStateManager.cpp#2319

requireUserInteraction seems to be always true when calling webNav->GoBack(GoForward), so we hit the underlying bug like bug 1644914.

Comment 11

[Popolon]

browser.navigation.requireUserInteraction is false on both 81 and 82b, and I didn't changed it.

Comment 12

[Johann Hofmann [:johannh]]

Attachment: Bug 1666095 - Fix requireUserinteraction usage in DoScrollHistory. r=smaug

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/384e69822ac0
Fix requireUserinteraction usage in DoScrollHistory. r=smaug

Comment 14

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/mozilla-central/rev/384e69822ac0

Comment 15

[Timea Cernea [:tbabos][inactive]]

Reproduced the issue on affected Nightly83.0a1 on Windows 10 x64.
Verified-fixed on latest Nightly 84.0a1 (2020-10-21) (64-bit) and Beta 83.0b2 on Windows 10 and Ubuntu 16.04.