macOS Back Swipe Behaviour Broken By Certain Extensions
Categories
(Core :: Panning and Zooming, defect, P3)
Tracking
()
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.
Comment 1•1 years ago
|
||
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.
Comment 2•1 years ago
|
||
Thanks for the report.
Could you please try using https://mozilla.github.io/mozregression/ to determine the Firefox change that broke this?
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
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
Comment 5•1 years ago
|
||
(In reply to paul from comment #4)
Seems to be fixed by setting the
dom.event.wheel-event-groups.enabled
mentioned in that commit tofalse
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?
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.
Comment 7•1 years ago
|
||
(In reply to paul from comment #6)
dom.event.wheel-event-groups.enabled
was set totrue
for me. I've never touched that setting before just now. This bug happens when it's set to true. Overriding it to befalse
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.
Comment 8•1 year ago
|
||
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.
Comment 9•1 year ago
|
||
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.)
Comment 10•1 year ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Comment 11•1 year ago
|
||
Set release status flags based on info from the regressing bug 1168182
Comment 12•1 year ago
|
||
Adding [apz-needsdiagnosis] tag until we determine whether the issue is with the affected addons, or in Firefox's own behaviour.
Updated•1 year ago
|
Updated•1 year ago
|
Comment 13•1 year ago
|
||
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.
Comment 14•7 months ago
|
||
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.
Comment 15•7 months ago
|
||
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.
Comment 16•7 months ago
|
||
Closing as INCOMPLETE for now. Please feel free to reopen if you're still experiencing this.
Updated•6 months ago
|
Description
•