1114872 - Duplicate mouse events in nested content process

Status: RESOLVED WONTFIX

(Core :: DOM: Events, defect)

Description

[Kershaw Chang [:kershaw]]

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

Comment 1

[Kan-Ru Chen [:kanru] (UTC+9)]

Should fixing bug 1020199 fixes this automagically?

Comment 2

[Kershaw Chang [:kershaw]]

(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?

Comment 3

[Kartikaya Gupta (email:[e-mail])]

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

Comment 4

[Kershaw Chang [:kershaw]]

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.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 6

[Kershaw Chang [:kershaw]]

(In reply to Kartikaya Gupta (email:[e-mail]) 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.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 8

[Kershaw Chang [:kershaw]]

Close this bug since we don't support nested-oop now.