Add a navigator interface for user activation state.

[mustaqahmed]

Fixes: #4008

• At least two implementers are interested (and none opposed):
  • General consensus reached a while ago: User activation API #4009 (comment)
• Tests are written and can be reviewed and commented upon at:
  • Add a WPT for navigator.userActivation, fix issue ref in old tests. web-platform-tests/wpt#35836
• Implementation bugs are filed:
  • Chrome: https://crbug.com/846858
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1791079
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=245240

(See WHATWG Working Mode: Changes for more details.)

---

/index.html ( diff )
/interaction.html ( diff )

[domenic]

Thanks for this! I pushed a few minor fixes for style things; please pull them before doing any work.

Unfortunately it turns out the normative prose for the getters here is not great and needs some work. The biggest problem is that this class is exposed to Worker and AudioWorklet, but I have no idea how it could work there.

If we restrict this only to Window (maybe that is OK, since it's only accessible in this PR via window.navigator?) then we can improve the getter definitions as follows. You need to define that each Navigator object (or, perhaps simpler, each Window object) has a corresponding UserActivation object; then, the userActivation getter steps can be defined to return that. For an example, see https://html.spec.whatwg.org/#associated-navigator .

Then, we need to define the hasBeenActive and isActive getter steps in a way that connects up to the actual normative prose for sticky and transient activation. I believe this would be done using something like:

The hasBeenActive getter steps are to return true if this's relevant global object has sticky activation; otherwise false.

with the understanding that this only ever works for the Window context, and would need to be redone in a Worker or AudioWorklet context.

[mustaqahmed]

Unfortunately it turns out the normative prose for the getters here is not great and needs some work. The biggest problem is that this class is exposed to Worker and AudioWorklet, but I have no idea how it could work there.

That's a good point: because Workers and Worklets are not exposed to users, there is no way these could be activated. Removed them from the Exposed interfaces.

If we restrict this only to Window (maybe that is OK, since it's only accessible in this PR via window.navigator?) then we can improve the getter definitions as follows. You need to define that each Navigator object (or, perhaps simpler, each Window object) has a corresponding UserActivation object; then, the userActivation getter steps can be defined to return that. For an example, see https://html.spec.whatwg.org/#associated-navigator .

Please check my latest patch.

Alternatively, we can move the first IDL definition here to Sec 6.4.1 where we defined "user-activation-states", but it seems more logical to me that the exposed pieces are separated from the (unexposed) data model in the browser. Thoughts?

Then, we need to define the hasBeenActive and isActive getter steps in a way that connects up to the actual normative prose for sticky and transient activation. I believe this would be done using something like:

The hasBeenActive getter steps are to return true if this's relevant global object has sticky activation; otherwise false.

with the understanding that this only ever works for the Window context, and would need to be redone in a Worker or AudioWorklet context.

Done.

[mustaqahmed]

Please take a look again.

[domenic]

LGTM, thanks! Can you file bugs on Gecko and WebKit and update the original post with them?

[mustaqahmed]

LGTM, thanks! Can you file bugs on Gecko and WebKit and update the original post with them?

Done.