Trigger HTML activation#230
Open
jesup wants to merge 1 commit into
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #124
This combines gamepad interaction with HTML's existing sticky/transient activation (https://html.spec.whatwg.org/#tracking-user-activation) model, per @marcoscaceres's review on #107 ("we probably want to layer this on top of HTML's 'triggered by user activation'") and this issue's suggestion to use the sticky-activation model directly, rather than defining a new gamepad-local activation concept as #107 attempted (that PR duplicated the existing spec's "contains a gamepad user gesture" definition under a colliding name and never reached HTML's real activation state -- I suggest closing it in favor of this PR).
This also matches existing shipped behavior: Chromium calls LocalFrame::NotifyUserActivation(kInteraction) from NavigatorGamepad::Gamepads() whenever GamepadComparisons::Compare() detects a qualifying button/axis transition on a visible page -- the same primitive mouse/keyboard input uses. This PR gives that behavior normative text, reusing the spec's existing "contains a gamepad user gesture" and fully active descendant of a top-level traversable with user attention conditions as the trigger, and HTML's activationnotification algorithm as the effect.
Note this extends HTML's own introduction of activation notification ("when a user interaction causes firing of an activation triggering input event... the user agent must perform the following steps before dispatching the event") — gamepad state changes aren't dispatched as that kind of event; they're observed by polling. I'm invoking the algorithm as a reusable procedure rather than a hard prerequisite check, consistent with how Chromium implements it (it calls the underlying primitive directly, not by synthesizing a fake input event). Flagging this for HTML editors in case they'd prefer activation-triggering-input-event itself be broadened instead of allowing direct invocation. I can change to that if requested.
Deliberately out of scope: the separate, older "gamepadconnected event" section (§17) has its own partially-duplicated algorithm with stale prose ("SHOULD be dispatched when the user presses a button or moves an axis") that looks like leftover text update gamepad state was meant to supersede. Left untouched here to keep this PR reviewable; worth a separate cleanup PR.
The following tasks have been completed:
Implementation commitment:
Preview | Diff