Skip to content

Consider exposing "Active Interaction" as a first class API (Related to: transient user activation) #72

@mmocny

Description

@mmocny

The implementation of ICP necessarily relies on:

  • Observing new interactions
  • Establishing an active context for them
  • Persisting and tracking that context across scheduling (i.e. AsyncContext Variable)

We currently read this internal value whenever we observe effects, such as dom modifications or same document navigation commits.

But, there are use cases where it may become valuable and interesting to expose this value as a public web API for developers to use.


One example that was recently given was to help differentiate when synthetic events trigger (i.e. play event on video element), to differentiate programmatically initiated effects from new real user interaction triggered effects.

(Today, it seems commonly recommended to observe the global (transient) user activation state before attempting to e.g. play unmuted video. But this is a global sticky bit that persists for many seconds.)

An alternative design which would satisfy the above might be to just expose interactionId on all Events that are dispatched (related to isTrusted and userInitiated values that already exist on (some) events).


FWIW this also reminds me a bit of: w3c/event-timing#108

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions