1882168 - Wheel events can be triggered in the wrong tab

Status: RESOLVED DUPLICATE of bug 1902017

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

Description

[Calixte Denizet (:calixte)]

Attachment: plop.html

STR:

• on Mac, open the attached html file in two adjacent tabs;
• start scrolling on the first tab in using the touchpad;
• stop scrolling and quickly switch to the other tab in using cmd+option+arrow (left or right).

The pink bar in the second tab shows "Wheel" which means that some wheel events have been received by the second tab even if they've been triggered in the first tab.

FYI, this bug has been found in the pdf.js context (see bug 1503412), a workaround has been implemented but it'd be better to fix this issue instead.
It works as expected in Chrome.

Comment 1

[Calixte Denizet (:calixte)]

I can reproduce the bug with a laptop on Windows 11. The STR is almost the same except that we must use ctrl+PageUp/PageDown to switch from a tab to another.

Comment 2

[Dan Robertson (:dlrobertson)]

I think this was probably introduced when we added support for wheel transactions. We probably should ensure that we terminate the wheel transaction on keyboard events in addition to mouse events.

Comment 3

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

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 4

[Dan Robertson (:dlrobertson)]

(In reply to Calixte Denizet (:calixte) from comment #1)

I can reproduce the bug with a laptop on Windows 11. The STR is almost the same except that we must use ctrl+PageUp/PageDown to switch from a tab to another.

Can you reproduce this with dom.event.wheel-event-groups.enabled set to false?

Comment 5

[Calixte Denizet (:calixte)]

Yes I can reproduce either on mac or on windows with the above pref set to false.

Comment 6

[Dan Robertson (:dlrobertson)]

(In reply to Calixte Denizet (:calixte) from comment #5)

Yes I can reproduce either on mac or on windows with the above pref set to false.

Hm that mostly rules out my theory that this is related to the wheel transations feature.

Comment 7

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

The severity field is not set for this bug.
:botond, could you have a look please?

For more information, please visit BugBot documentation.

Comment 8

[Dan Robertson (:dlrobertson)]

We talked about this in the last APZ meeting

Comment 9

[Hiroyuki Ikezoe (:hiro)]

After switching to the new tab, we set the layersId for the new tab here and the layersId is used to tell which BrowserParent is the target for the event in EvenStateManager::DispatchCrossProcessEvent().

In APZ we have an active pan gesture block so that we won't route it to the new tab's APZCs

I am not sure we still need to have apz-needsdiagnosis here.

Comment 10

[Botond Ballo [:botond]]

Recording for reference two potential solution ideas we discussed:

1. Asking the OS to stop sending momentum events when something that invalidates the target, like a tab switch, occurs. The feasibility of this may depend on the OS. Markus suggested that on Mac there may be a private API for this.
2. Filtering out subsequent momentum events at the APZ level in such a scenario. We seem to already successfully prevent them from causing scrolling, but we can also prevent their dispatch to content by returning a status of eConsumeNoDefault from ReceiveInputEvent.

We may in fact want to do both -- (2) so that we avoid issues like this in a reliable and platform-independent way, and where possible also (1) to avoid doing unnecessary processing.

Comment 11

[Dan Robertson (:dlrobertson)]

This no longer is reproducible with the patches from bug 1902017.

Comment 12

[Dan Robertson (:dlrobertson)]

This seemed to be fixed by the patches landed by bug 1902017 and friends.