Intervention: Force touch events to be uncancelable if the main thread is unresponsive. |
|||||
Issue descriptionChange description: Replace the Touch Ack Timeout with an intervention which forces touch events to be uncancellable when the main thread is busy, allowing scrolling to take place immediately on the compositor thread. Details here: https://docs.google.com/document/d/1_P6dw4YXePVXssUhg4DicU7T2f-6rt7A1OxniLvDtzo/edit Changes to API surface: No API surface changes. Links: Public standards discussion: None. This intervention is explicitly allowed by the current Touch Event spec. https://w3c.github.io/touch-events/#cancelability Support in other browsers: Other browsers don't implement this precise intervention, but we do see interventions meant to address the same issue. Safari: Safari has some odd behavior around touch event handlers cancellability when the main thread is busy, but it isn’t consistent. Edge: Edge appears to have something equivalent to the Touch Ack Timeout (verified experimentally on http://rbyers.github.io/touch-timeout.html) Firefox: The "APZ content response timeout" is equivalent to our Touch Ack Timeout. https://bugzilla.mozilla.org/show_bug.cgi?id=1247280
,
Feb 10 2017
,
Feb 13 2017
,
Mar 22 2017
,
Aug 2 2017
,
Sep 12 2017
This issue has been automatically relabelled type=task because type=launch-owp issues are now officially deprecated. The deprecation is because they were creating confusion about how to get launch approvals, which should be instead done via type=launch issues. We recommend this issue be used for implementation tracking (for public visibility), but if you already have an issue for that, you may mark this as duplicate. For more details see here: https://docs.google.com/document/d/1JA6RohjtZQc26bTrGoIE_bSXGXUDQz8vc6G0n_sZJ2o/edit For any questions, please contact owencm, sshruthi, larforge
,
Feb 23 2018
We decided not to follow up on this. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 by tdres...@chromium.org
, Jan 24 2017