1058255 - APZ doesn't get a prevent-defaulted notification until a touchmove is dispatched

Status: RESOLVED WONTFIX

(Core :: Panning and Zooming, defect)

Description

[Doug Sherk (:drs) (inactive)]

(In reply to Botond Ballo [:botond] from bug 1037066 comment #20)
> I investigated this a bit and discussed it with Kats and Doug. Summarizing:
> 
> The time required for content to send a prevent-default=no notification to
> APZ, and APZ to send back the APZStateChange::StartTouch message that
> triggers the :active state, is not the problem. This typically takes just a
> few milliseconds.
> 
> The problematic case is when you hold your finger down but do not move it,
> so that a touch-start is generated but not a touch-move. Since content is
> allowed to prevent-default the touch on the first touch-move as well as on
> the touch-start, it does not send the prevent-default=no message until the
> first touch-move is received and that has not been prevent-defaulted. Thus,
> in the case where there is no touch-move, a prevent-default=no message is
> never sent, and APZ waits for the full 300 ms before processing the touch
> block and sending the StartTouch message.
> 
> Doug's suggestion in comment 15 would not solve this problem - content would
> have to wait for the touch-move that never arrives just as much as APZ does,
> or else risk getting a false-positive for querySelector(':active') as
> mentioned in comment 18.
> 
> Instead, Kats suggested getting widget code, such as nsAppShell, to generate
> a touch-move event immediately after a touch-start, with the same
> coordinates as the touch-start. The gesture detection code can handle this
> gracefully (i.e. it won't mistakenly treat it as a pan gesture, before there
> is a tolerance threshold for that), but it would ensure that any touch-move
> listener on the content side that wants to prevent-default the touch block
> does so right away.

Comment 1

[Doug Sherk (:drs) (inactive)]

This was attempted in bug 1037066's attachment 8472682 [details] [diff] [review], but was backed out due to causing bug 1049250, bug 1055203, and bug 1055214.

Comment 2

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

Did you ever investigate the regressions? Do you recall what we did wrong/why they happened?

Comment 3

[Doug Sherk (:drs) (inactive)]

No, I haven't investigated this any further. As far as I know, everything that we do know is already documented in bug 1037066.

Comment 4

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

Pretty sure we're not going to fix this now, so closing as WONTFIX. I'm open to discussing this if you disagree. In general I think a better solution for these types of problems is to just remove the touch listener if possible. Now that we have the event-regions code working, we should only wait for the touch listener to run if we know that there is one in that particular area.