Closed Bug 1058255 Opened 7 years ago Closed 6 years ago

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

Categories

(Core :: Panning and Zooming, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: drs, Unassigned)

References

Details

(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.
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.
Did you ever investigate the regressions? Do you recall what we did wrong/why they happened?
Flags: needinfo?(drs.bugzilla)
No, I haven't investigated this any further. As far as I know, everything that we do know is already documented in bug 1037066.
Flags: needinfo?(drs.bugzilla)
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.