Closed Bug 1114872 Opened 6 years ago Closed 3 years ago

Duplicate mouse events in nested content process

Categories

(Core :: DOM: Events, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: kershaw, Unassigned)

References

Details

Due to that APZ is not working in nested content process now (see bug 1020199), synthesized mouse events are produced from touch events in TabChild [1]. It means we will get duplicate mouse events in nested content process.

[1] http://dxr.mozilla.org/mozilla-central/source/dom/ipc/TabChild.cpp#2664
Blocks: nested-oop
Should fixing bug 1020199 fixes this automagically?
(In reply to Kan-Ru Chen [:kanru] from comment #1)
> Should fixing bug 1020199 fixes this automagically?

Yes, I think so.
Or should we find a way to filter unnecessary mouse events temporarily?
Depends on: 1020199
It's not clear to me how fixing bug 1020199 would automatically fix this but I agree that it is probably a prerequisite. Also posting this link here because it may come in handy in the future: https://wiki.mozilla.org/Platform/Input/Touch
The event dispatching by IPC in nested oop case would be like:

+---------+ SendRealTouchEvent  +----------+ SendRealTouchEvent  +----------+
|         |-------------------->|          |-------------------->|          |
|   B2G   |                     | Content  |                     | Content  |
| Process | SendHandleSingleTap |Process(A)| SendRealMouseEvent  |Process(B)|
|         |-------------------->|          |-------------------->|          |
+---------+                     +----------+                     +----------+

Note that in TabChild::RecvHandleSingleTap of A, synthesized mouse events are fired to the target which is in B. In TabChild::RecvRealTouchEvent of B, TabChild::UpdateTapState is called since APZ is not enabled in B. In TabChild::UpdateTapState, another synthesized mouse events are created and fired to the target.
Nice diagaram! :) That makes it clear - yes, fixing bug 1020199 properly should address this. I would expect the final flow to look like this:

+---------+ SendRealTouchEvent  +----------+ SendRealTouchEvent  +----------+
|         |-------------------->| Content  |-------------------->|          |
|   B2G   |                     |Process(A)|                     | Content  |
| Process | SendHandleSingleTap +----------+                     |Process(B)|
|         |----------------------------------------------------->|          |
+---------+                                                      +----------+

and since APZ will be enabled in both A and B none of those touch events will get converted into mouse events, only the single-tap delivered to B will get converted.
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #5)
> Nice diagaram! :) That makes it clear - yes, fixing bug 1020199 properly
> should address this. I would expect the final flow to look like this:
> 
> +---------+ SendRealTouchEvent  +----------+ SendRealTouchEvent  +----------+
> |         |-------------------->| Content  |-------------------->|          |
> |   B2G   |                     |Process(A)|                     | Content  |
> | Process | SendHandleSingleTap +----------+                     |Process(B)|
> |         |----------------------------------------------------->|          |
> +---------+                                                      +----------+
> 
> and since APZ will be enabled in both A and B none of those touch events
> will get converted into mouse events, only the single-tap delivered to B
> will get converted.

I think B2G process is not able to send SingleTap to B directly, since only A knows the event should be dispatched to B. So, the event dispatching flow should be still the same as the first diagram.

In addition, I think this bug is really important for enabling nested oop in B2G. May I know your schedule about fixing bug 1020199? Thanks.
Flags: needinfo?(bugmail.mozilla)
A will have the layer tree from both B and C and so it will know that the tap needs to be dispatched to C, and will be able to do so directly. There are still cases where the tap will need to go through B but those should be rare.

At the moment we don't have a clear schedule with respect to fixing bug 1020199. It should not be a lot of work but in Q1 we will be spending most of our time on off-main-thread input so most likely we won't get to it until after that. Likely in 3.0 rather than 2.2 but i can't say for sure at this point. If you need it done sooner you can discuss the priority with Milan.
Flags: needinfo?(bugmail.mozilla)
Close this bug since we don't support nested-oop now.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.