`setMediaKeys()` modifies observable state and internal flags "in parallel"

[xhwang-chromium]

Created with the help of AI.

Description

The setMediaKeys() algorithm in Section 7.2 of the Encrypted Media Extensions (EME) specification performs several state mutations while running "in parallel." This pattern violates the standard web platform concurrency model as defined in the HTML Standard, specifically Section 8.1.7.5, "Dealing with the event loop from other specifications".

According to the HTML Standard, algorithms running "in parallel" must not directly manipulate main-thread objects:

"The next complication is that, in algorithm sections that are in parallel, you must not create or manipulate objects associated to a specific realm, global, or environment settings object".

Modifying observable attributes or internal flags used for synchronous checks from a background thread introduces data races and non-deterministic behavior:

"Stated in more familiar terms, you must not directly access main-thread artifacts from a background thread. Doing so would create data races observable to JavaScript code, since after all, your algorithm steps are running in parallel to the JavaScript code".

Specific Steps in EME Section 7.2

After entering parallel execution in Step 5, the algorithm performs the following unsafe operations:

1. Step 5.3.2.1: "Set the mediaKeys attribute to null".
2. Step 5.4: "Set the mediaKeys attribute to mediaKeys".
   • Issue: The mediaKeys attribute is a script-observable property of the HTMLMediaElement. Changing it off the main thread allows a script to potentially observe a stale or transitioning value.
3. Step 5.5: "Let this object's attaching media keys value be false".
   • Issue: This flag is used as a synchronous guard in Step 1 ("If this object's attaching media keys value is true, return a promise rejected with an InvalidStateError"). Clearing it in parallel creates a logic race where a subsequent synchronous call might read an incorrect flag state before the background thread completes its write.

Proposed Fix

The algorithm should be updated to follow the pattern used in other sections of the spec and broadly across WHATWG/W3C. All observable state changes, flag updates, and the final promise resolution should be moved inside a queued task as described in HTML Standard Section 8.1.7.5.

Example Restructuring:

• Perform the CDM association logic in parallel.
• Queue a task to:
  1. Update the mediaKeys attribute.
  2. Clear the attaching media keys flag.
  3. Resolve/Reject the promise.
  4. Run the Attempt to Resume Playback If Necessary algorithm.

[chrisn]

See also #562 for more examples that may need updating.

[xhwang-chromium]

We discussed this today, and agreed with the findings in this issue.

I took a look at Chromium's implementation as well. The code is here.

The implementation follows what the current spec says. But it is still thread safe because the kMiscPlatformAPI task runner in SetMediaKeysHandler still executes on the main thread.

That said, the spec language is still problematic, because there's no guarantee that the task runner will always be on the main thread. I'll give it a try to update the spec language.