Intent to Implement: Gesture Delegation

[Becca Hughes]

Contact emails

becca...@chromium.org, mlam...@chromium.org

Spec

https://github.com/WICG/gesture-delegation

Tag review: https://github.com/w3ctag/design-reviews/issues/199

Summary

Add a allowedGestureDelegation attribute to <iframe> that allows the page to delegate gestures to child frames in certain contexts.

Motivation

Autoplay on mobile requires a user gesture (as do some other APIs e.g. vibration). If content is in embedded on a page it cannot use autoplay unless a gesture occurs on the embedded page itself. This allows gestures to be delegated from the parent page to the embedded page and limit the behavior without breaking the experience.

Risks

Edge: No signals

Firefox: No signals

Safari: No signals

Web developers: No signals

Ergonomics

This part of Unified Autoplay.

Activation

Developers can easily change the autoplay policy in chrome://flags to take advantage of this.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=766090

Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/6025124331388928

Requesting approval to ship?

No

[Philip Jägenstedt]

+Ian Clelland, how do you think this fits in with Feature Policy? Most things of this general shape (attributes on iframes to allow stuff) are being transitioned to Feature Policy. Would it make sense here too?

--
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/CANi3S8mOEp_sQN-W5EqA7%3Duu8uzWiDyJmqS4ef6RydEXuJiC_w%40mail.gmail.com.

[d...@google.com]

The security questionnaire should probably cover "GestureJacking."  That is, the case where a malicious outer page uses this feature to affect a victim frame from a different origin.  Right now the feature only seems to regulate autoplay and vibration, so it's no big deal, but in the future maybe more things will rely on activation (?).  Behavior w.r.t. sandboxed and nested frames should probably be considered as well.

Maybe it would be sufficient allow gesture delegation only for same-origin scenarios?

[Jeffrey Yasskin]

I started a discussion along these lines in https://github.com/WICG/gesture-delegation/issues/4.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYeXGEKRMNxFu80OFQwjsbkc8SXVdUM89VAsq1GMnCbDeg%40mail.gmail.com.

[Ian Clelland]

I've responded on the github issue, but to recap here: this proposal actually came out of a desire to separate the question of "what features are allowed in a child frame?" from "when is the child frame considered 'activated'?" The first question can be answered through feature policy, while the second one is handled by this proposal.

It means that you can use feature policy to unconditionally block a frame from using a feature, but if you don't do that -- if you allow the feature -- then you can use gesture delegation to control whether the child frame should be activated when the parent frame is, or whether it requires its own gesture (which is the only allowed behaviour today).

Trying to handle all of this within feature policy looked like it was going to lead to features like "vibrate", "vibrate-after-activation", "vibrate-without-activation", (and similar redundancy for other APIs) and more complicated rules for combining policies in subframes. 

[Philip Jägenstedt]

That makes sense, thanks Ian!