Intent to Implement: Ability to Query User Activation State

[Dave Tapuska]

Contact emails dtap...@chromium.org Spec https://github.com/dtapuska/useractivation Summary

Add ability to query User Activation state in javascript. Motivation Some APIs are restricted by the notion of User Activation (https://html.spec.whatwg.org/multipage/interaction.html#activation). eg. requestFullScreen, autoplay, window.open Using this restriction is powerful in preventing annoying behavior that some javascript can take without it. However an application may wish to use this information inside the application itself and it has no way to do that today. This proposal is to add ability to query the User Agent state.

One such example is a web page with an embedded iframe. The iframe may postMessage a message to the parent frame to do something. The parent frame determines if it should honor this request or not.
Interoperability risk Firefox: No public signals Edge: No public signals Safari: No public signals Web developers: Positive Compatibility risk None Ongoing technical constraints Consistent definition of what is a user activation across browsers.

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

OWP launch tracking bug https://crbug.com/836826 Link to entry on the Chrome Platform Status https://www.chromestatus.com/features/5131233151418368 Requesting approval to ship? No

[Anne van Kesteren]

On Tue, Jun 5, 2018 at 6:53 PM, Dave Tapuska <dtap...@chromium.org> wrote:
> Consistent definition of what is a user
> activation across browsers.

So when it comes to user activation my impression was that Chrome was
experimenting with a different model and if successful would try to
get other browsers to adopt that. However, now I get the impression
you're instead building new APIs on top of it, such as this one, that
on the face of it seem hard to adopt in other browsers as they don't
have the same (experimental?) model. I hope I'm missing something.


--
https://annevankesteren.nl/

[Ashley Gullen]

If pages can query the user activation state, why not add an event that fires when it changes? This will address use cases like games that want to play title music at the first opportunity. Currently pages have to listen for an undocumented list of magic events that qualify as a user gesture, and the list has been changing over time (and breaking things). Adding an event for this would simplify that and protect against future changes.

Some previous discussion here: https://discourse.wicg.io/t/usergesture-event/2774

--
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+unsubscribe@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAHXv1wn_TeUr-1%3DMgU8_0-gW8XNMU0KY7F-XSqqtq%3DduzKJO9g%40mail.gmail.com.

[Dave Tapuska]

To annevk@'s comments:

Yes chrome is experimenting with a different implementation of user activation that we hope is simpler. This API is independent of that. 

Both the current model and the previous model (and various specifications) use the concepts exposed in this API. 

1) Whether there is a user gesture active. (different browser implementations may change how this is defined; but there should be a common set that is currently called out in the HTML spec that must support)

2) Whether there has been a user gesture seen on the page before.

To ashley@'s comments:

While I don't disagree with the capability to determine it dynamically changing we have concerns about performance and how this influences a frame tree. Since every frame in the frame tree sees that a user gesture is active (and conversely not active) that means for the dispatch of a single click you'll need to dispatch two change events to every frame in the the stacking context of the hit test. Note in Chrome (wrt OOPIF) these are different processes. This seems quite expensive and this is why we didn't propose this yet. Conversely a read only bit in a frame can be efficiently set on a number of frames via a number of avenues.

dave.

--
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/CADnb78ifOn%3DVZigpveAS6mx2WOXZ8JmJdbvJ0wUEsEoCDVGzKw%40mail.gmail.com.

[Anne van Kesteren]

On Wed, Jun 6, 2018 at 3:28 PM, Dave Tapuska <dtap...@chromium.org> wrote:
> Both the current model and the previous model (and various specifications)
> use the concepts exposed in this API.
> 1) Whether there is a user gesture active. (different browser
> implementations may change how this is defined; but there should be a common
> set that is currently called out in the HTML spec that must support)

What the HTML specification has is some form of stack inspection
though, not something stored globally. (It seems the difference could
manifest itself through timers, or callbacks invoking functions
defined in other globals.)

> 2) Whether there has been a user gesture seen on the page before.

This is not a concept I'm aware of in the standard.


--
https://annevankesteren.nl/

[Dave Tapuska]

Whether it is stack inspection or not doesn't change the API surface. (FWIW: Gecko, WebKit and Blink do not implement stack based schemes and have timeouts)

With regard to has been a user gesture in the frame before:

I thought other specs formally called this out but it appears autoplay isn't specified this way yet in HTML spec

https://developers.google.com/web/updates/2017/09/autoplay-policy-changes

Vibration also uses this concept: https://github.com/WICG/interventions/issues/47

Likewise webvr, webxr, focus handling (when the virtual keyboard appears on a focus call) and history interaction are all gated on the concept of having to initially interact with the page. 

dave.