Closed Bug 1058255 Opened 7 years ago Closed 6 years ago
APZ doesn't get a prevent-defaulted notification until a touchmove is dispatched
(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?
No, I haven't investigated this any further. As far as I know, everything that we do know is already documented in bug 1037066.
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
6 years ago
See Also: → 1141127
You need to log in before you can comment on or make changes to this bug.