Intent to Implement and Ship: Escape key is not a user activation
Mustaq Ahmed
Contact emails
Explainer
No explainer needed, this is a subtle change in a low-level behavior.
Spec discussion
There is currently no spec to define exactly which user inputs trigger user activation, spec discussion here. Browsers define these triggers inconsistently, here is a chart.
We plan to start working on a spec for activation triggers once User Activation v2 PR lands.
We are skipping the tag review process because this is a subtle change in Chrome behavior and doesn’t have any dev exposed API.
Summary
Hitting the Escape key shouldn’t activate the page.
Motivation
Browsers prevents calls to abusable APIs (like popup, fullscreen, vibrate etc) unless the user activates the page through direct interactions. Not all interactions trigger user activation: for example, clicking on a link or typing in a textbox does but swiping fingers on screen or hovering mouse cursor doesn't. Since users never intends to interact with the page through the ESC key, it should not trigger user activation.
Most importantly, ESC key activation triggering recently turned out to be the root cause of one abuse vector (here is a restricted bug).
Risks
Interoperability and Compatibility
Through this change, Chrome ESC key behavior will become like Firefox’s. Bigger interop question is moot since browsers differ widely, see the chart above.
There is a very little compat risk: we don’t know if there are actual sites that rely on ESC key to trigger popups, vibration etc, and there is no easy way to measure/predict the usage. We investigated Fullscreen and KeyboardLock as two Chrome APIs that rely on ESC key, and none of them rely on user activation from ESC key (because both APIs “undo” their effects through this key).
Edge: No signals.
Firefox: Shipped (ESC keys are already ignored, see the chart above).
Safari: No signals.
Web / Framework developers: No signals.
Ergonomics
None: we are not aware of any usage of activation tied specifically to ESC key.
Activation
Not applicable because this doesn’t expose any dev-facing API.
Debuggability
Not applicable.
Will this feature be supported on all six Blink platforms?
Yes (Windows, Mac, Linux, Chrome OS, Android, and Android WebView).
Is this feature fully tested by web-platform-tests?
Pull request (generated from our Chrome CL): github.com/web-platform-tests/wpt/pull/16566.
Link to entry on the feature dashboard
https://www.chromestatus.com/feature/5302245493047296.
Requesting approval to ship?
Yes.
Chris Harrelson
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO5hNYgQiJM58smjXB-URAo33mqvwAcubHWZn1wMifUOtg%40mail.gmail.com.
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-7HC22AnAB5BTPHMPZRvNvPRj4T9%3D7g9_nX-eBWFxeRA%40mail.gmail.com.
Alex Russell
Mustaq Ahmed
What's the behavior here today in browsers other than Firefox?
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ba9f5a8e-b13e-49d8-80a9-eff937070353%40chromium.org.
Rick Byers
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAB0cuO7EUSk6-7YdwBZhgFaordTYpBqNPnsu5QpPx4kYLovXvQ%40mail.gmail.com.