1 of 22

Standardizing�User Activation behavior

Mustaq Ahmed, Domenic Denicola

{mustaq,domenic}@chromium.org

TPAC, 18 Sep 2019

2 of 22

Overview

  1. User activation in the Web today
  2. Chrome’s user activation changes
  3. Proposed spec changes
  4. Discussion

Goals:

  • Clarify the scope of our pull request
  • Attempt to resolve comments F2F to ease consensus

3 of 22

What is “User Activation”?

  • It’s the “state” representing active user engagement
  • Prevents abuse of sensitive APIs
    • E.g. don’t allow popup or fullscreen w/o user interaction

​

  • “User Gesture” means the same thing, but it’s misleading
    • A swipe gesture is not a “user gesture”!

4 of 22

User Activation in the Web today

5 of 22

A first look at spec vs reality

Full spreadsheet

Too vague and misleading

...

#yes

6 of 22

Let’s look at window.open

Events allowing popups

expiry

through setTimeout

through Promise

Through postMessage

Consumes?

in click handler

Based on a 2017 comparison

7 of 22

Current spec

Idea: “triggered by user activation”

// Not allowed:

body.onload = () => window.open();

​

// Allowed:

body.onclick = () => window.open();

​

// Allowed even with arbitrary "chaining":

body.onclick => setTimeout => window.open()

body.onclick => setTimeout => setTimeout … => window.open()

body.onclick => setTimeOut => setTimeout => Promise … => window.open()

​

8 of 22

Problems with current spec

  1. Missing details (vs browsers)
    • No expiry/timeout
    • No consumption
    • Undefined cross-frame visibility
  2. Chaining ≠ causality tracking
    • Can’t chain async tasks (dev complain)
    • Can be abused for unrelated tasks
    • “Forked” chain ⇒ global state
  3. Unclear activation triggering events

​

setTimeout

popup

setTimeout

popup

setTimeout

popup

click

setTimeout

popup

9 of 22

The Web is broken

10 of 22

Chrome’s user activation changes

11 of 22

Fixing existing impl was not an option...

12 of 22

… so we started from scratch

  • Early 2017: Questioned the need for complexity
  • Mid 2017: Proposed a simple model, aimed to encourage other browsers
  • 2018: Implementation, refinement, regressions …
  • Early 2019: Successfully shipped User Activation v2 in M72, yayy!

​

Main bug. Chrome impl details.

13 of 22

All about “User Activation v2”

  1. User activation state is a timestamp in a Window/Frame
    • Eliminates chaining (causality tracking)
    • Back-to-back user activations merge into one
  2. Well-defined visibility across frame boundary
    • Parent can see child’s activation, not vice versa
    • Exception: same-origin frame
    • Demo
  3. Three levels user activation dependency
    • Consuming, transient, and sticky.

​

​

Immediately fixed�quite a few bugs,�upto 6+ years old!

14 of 22

For web devs: consistency across the board

// Child frame code:

someButton.addEventListener("click", () => {

parent.postMessage("hi_there", parent_origin);

parent.postMessage("open_popup", parent_origin);

});

​

// Parent frame code:

window.addEventListener("message", (e) => {

if (e.data === "open_popup") window.open("...");

});

​

​

Similar for any “chaining”: setTimeout, Promise, etc.

15 of 22

Proposed spec changes

16 of 22

Summary of our spec proposal

  • (Re)define “User Activation” model
    1. Activation state in Window/Frame
    2. Visibility only in container (ancestor) frames
    3. Three levels of API dependency (consuming, transient, sticky)
  • Rephrase references within HTML spec
    • “triggered by user activation” → “when Window is activated”

Pull request. Spec issue. Spec explainer

17 of 22

Interop is our ultimate goal

Seeking commitments from other browser.

​

Comments received so far:

  1. Scope of the change
    • Effect on popups and autoplay
  2. Testing the changes
  3. Input events defining user activation

18 of 22

Comment #1: Scope of the PR

User Activation

Permissions

<input type=...>

Higher level dependency

window.open

autoplay

media.play

Vibration

Clipboard

WebShare

WebUSB

WebBluetooth

Related bigger picture:�Web capability guards

19 of 22

Comment #2: Testing

Challenges:

  1. User activation not exposed� ⇒ Rely on gated APIs ⇒ Tests now depend on other things
  2. Outcomes of some gated APIs are not detectable

​

We added these tests, try them in different browsers:

​

Comparison makes�the most sense�with “simple” APIs

20 of 22

Comment #3: Events defining user activation

Not covered by this PR:� doesn’t make sense w/o a clear model

See our plan in the next slide.

21 of 22

Planned sequence of changes

(Updated based on feedback received at the TPAC 2019 session)

  1. Model change first
  2. Fix simple APIs
  3. Complete standardizing JS exposed User Activation state
  4. Define input events (issue, current state)
  5. Gradually move to more complex APIs�(Spec all APIs one day?)

22 of 22

Comments? Questions?

​

(Also continue follow-up discussion in the pull request)