936678 - Standardize input block handling on B2G, Android, and Metro

Status: RESOLVED DUPLICATE of bug 1009733

(Core :: Panning and Zooming, defect)

Description

[Jim Mathies [:jimm]]

From a write up kats did for a discussion we had about this today - 

--
My previous definition of "input block": http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/gfx/TouchEventHandler.java#26 - I don't think this is a good definition going forward; with multi-APZC we want to be able to seamlessly transition between pinching (handled by an APZC high in the tree) to panning (handled by an APZC lower in the tree) just by lifting one touch point. However lifting of touch points does not begin a new "input block" according to the old definition so things get confusing. We need a new definition of "input block" that is more granular. Here is my proposal:
* An "input block" is defined as a contiguous sequence of events starting from a pointerdown/pointerup event up to but not including the next pointerdown/pointerup event.
* A "preventable input block" is defined as an input block that starts with a pointerdown event. The default APZ behaviour for this input block can be prevented by content, by calling preventDefault on the touchdown or first touchmove event.
* Any input block that is not a "preventable input block" is called a "secondary input block" and inherits the prevented status from the most recent preventable input block.
* Each input block will be directed to a single APZC instance. Note in particular that a secondary input block that is prevented (by inheritance) can by directed to a different APZC instance than the preventable input block.
--

Clients that control input to apzc tree managers should follow a standard set of rules regarding the handling of input block touchstart and touchmove events, calls to ContentReceivedTouch, and event filtering depending on whether content is consuming touch.

The exact rules that clients must follow are still TBD, but for starters:

1) For each preventable input block, clients are required to make one call (and one call only) to ContentReceivedTouch with the appropriate prevent default flag.
2) For blocks that are default prevented, clients are required to send one touchcancel to the target apzc.
3) Clients are expected to filter input to the apzc for each input block that is prevented after sending touchcancel.
4) In cases where content is not consuming, clients must deliver events to the dom when the apzc ignores the input.
5) Clients should not deliver events to the dom if the apzc is consuming them (except in the case of first touchstart/touchmove).

TBD: default prevented modes per the w3c touch spec. Depending on which event preventDefault is called, touch events will still need to be delivered to the apzc so certain gestures can be generated.

Comment 1

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

Oh, I thought based on the discussion we didn't need the new definition, because we never run into the scenario where lifting a touch point means that the events go to a different APZC instance.

We still need to implement input blocks properly across all platforms, but I thought the "previous definition" would suffice (and it's simpler).

Comment 2

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

This was basically done in bug 1009733 and friends for B2G and Metro. Bug 1049136 does it for apz on Fennec.