Closed Bug 1851378 Opened 1 year ago Closed 2 months ago

macOS Back Swipe Behaviour Broken By Certain Extensions

Categories

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

Firefox 117
defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
firefox-esr102 --- unaffected
firefox-esr115 --- wontfix
firefox117 --- wontfix
firefox118 --- wontfix
firefox119 --- wontfix
firefox120 --- wontfix

People

(Reporter: paul, Unassigned)

References

(Regression)

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:109.0) Gecko/20100101 Firefox/117.0

Steps to reproduce:

Install HoverZoom extension - broken on any website
Install Something Awful Last Read Redux - broken on forums.somethingawful.com

Actual results:

With these add-ons installed, the macOS forward and backwards swipe gestures are broken.
Vertical scroll on a page, and you are unable to use the gestures for forward/back for around 3 seconds after you've stopped scrolling.
This is reproducible 100% of the time.

I've tested on 117 and Nightly and the issue persists.

The reason I think this is a regression in Firefox vs the fault of the add-ons is that Something Awful Last Read Redux has not been updated since 10 Jul 2022, worked flawlessly before 116, and is now affected by this bug.

Disabling both extensions restores correct behaviour.

Expected results:

macOS swipe forward/back should work correctly immediately after vertical scrolling even with these add-ons enabled.

The Bugbug bot thinks this bug should belong to the 'Core::Panning and Zooming' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Panning and Zooming
Product: Firefox → Core

Thanks for the report.

Could you please try using https://mozilla.github.io/mozregression/ to determine the Firefox change that broke this?

Flags: needinfo?(paul)

What a cool tool!

Turns out it's quite a bit older than I thought - https://phabricator.services.mozilla.com/D172025

Last good: 275a0c35
Final bad: cb782a3a

Flags: needinfo?(paul)

Seems to be fixed by setting the
dom.event.wheel-event-groups.enabled
mentioned in that commit to false

so it would seem it is indeed something to do with that setting

(In reply to paul from comment #4)

Seems to be fixed by setting the
dom.event.wheel-event-groups.enabled
mentioned in that commit to false

so it would seem it is indeed something to do with that setting

dom.event.wheel-event-groups.enabled has been set to true by default for a while. Do you have the default value set? Is the previous behavior restored if the value of dom.event.wheel-event-groups.enabled is changed?

Flags: needinfo?(paul)

dom.event.wheel-event-groups.enabled was set to true for me. I've never touched that setting before just now. This bug happens when it's set to true. Overriding it to be false stops the bug from happening.

So it's something with that setting being true which breaks these gestures.

Flags: needinfo?(paul)

(In reply to paul from comment #6)

dom.event.wheel-event-groups.enabled was set to true for me. I've never touched that setting before just now. This bug happens when it's set to true. Overriding it to be false stops the bug from happening.

So it's something with that setting being true which breaks these gestures.

Under normal circumstances it wouldn't break swipe to navigate gestures, but there is probably something in the addon that is interacting poorly with the changes made to fix bug 1168182. Hoverzoom does seem to have support for Chrome and the changes made to fix bug 1168182 make our wheel events behave more like Chrome, but perhaps there is some Firefox specific behavior in hoverzoom used for wheel events.

Keywords: regression
Regressed by: 1168182

Going to mark as P3/S3 since this only impacts a non-standard configuration. I'm curious why wheel event transactions would impact swipe to nav gestures in this case. I'd be curious to see if web content could trigger a similar scenario.

Severity: -- → S3
Priority: -- → P3

I'm assuming this is WONTFIX for 118 (current beta, approaching release) at this point, since any fix probably wouldn't arrive in time, and since we've already been shipping with this bug since 113, based on the regressor. --> Marking as-such.

(Also, removing "...since 116" from the bug title, since it sounds like that turned out to be incorrect, per comment 3.)

Summary: macOS Back Swipe Behaviour Broken By Certain Extensions Since 116 → macOS Back Swipe Behaviour Broken By Certain Extensions

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

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

Adding [apz-needsdiagnosis] tag until we determine whether the issue is with the affected addons, or in Firefox's own behaviour.

Whiteboard: [apz-needsdiagnosis]

Honestly I don't quite understand what happens inside the addons though, in the case of "Something Awful Last Read Redux", it listens "mousewheel" events. Changing the event names to "wheel" makes swipe navigation works as expected. So my best guess is that the addon has a workaround for the wheel transaction behavior on Chrome originally by using "mousewheel" events, and now Firefox's wheel transaction behavior is same as Chrome, but unfortunately the workaround doesn't work because of the "mosuewheel" event listener.

In the case of HoverZoom, though there are three HoverZoom-ish extensions, Hover Zoom+ for Firefox, Hover Zoom+ (Official) and hooverZoom, I can't see any issues with the extensions.

Depends on: 1864884
Whiteboard: [apz-needsdiagnosis]

Paul, could you please check if this issue still occurs in the latest (2024-07-10) Nightly?

The issue that this was marked as dependent on (or more precisely, the issue that that's been marked as a duplicate of) has been resolved in this nightly.

Flags: needinfo?(paul)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:botond, since the bug has recent activity, could you please find another way to get the information or close the bug as INCOMPLETE if it is not actionable?

For more information, please visit BugBot documentation.

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

Closing as INCOMPLETE for now. Please feel free to reopen if you're still experiencing this.

Status: NEW → RESOLVED
Closed: 2 months ago
Flags: needinfo?(botond)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.