Require system focus for gamepad user gesture

[nondebug]

Closes #206

The following tasks have been completed:

• Modified Web platform tests (link to pull request)

Implementation commitment:

• WebKit
• Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=)
• Gecko (https://bugzilla.mozilla.org/show_bug.cgi?id=)

---

Preview | Diff

[marcoscaceres]

This seems reasonable. I need to check if WebKit already does this or not.

[nondebug]

This seems reasonable. I need to check if WebKit already does this or not.

I think WebKit on macOS already requires focus even for normal gamepad inputs because it uses Game Controller API which requires focus.

[marcoscaceres]

We might actually want this:
https://html.spec.whatwg.org/multipage/interaction.html#fully-active-descendant-of-a-top-level-traversable-with-user-attention

• Fully active
• visibly requirement
• and system system focus!

[marcoscaceres]

This looks ok to me.

[Copilot]

Pull request overview

Updates the Gamepad spec’s “gamepad user gesture” handling to require the relevant document to have user attention (i.e., be focused/active) before the initial gesture unlocks exposure of gamepad data, addressing issue #206’s cross-tab gesture concerns.

Changes:

• Gate setting Navigator/[[hasGamepadGesture]] on the associated document being a fully active descendant of a top-level traversable with user attention.
• Hoist the associated Document lookup earlier in the “update gamepad state” algorithm (so it can be used for the new focus/user-attention check).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The condition uses “|document| is a Document/fully active descendant …” but |document| is defined as Document? and can be null. Add an explicit |document| is not null (or change the condition to handle null) before applying the HTML definition, to avoid a type-mismatched check and make the focus requirement unambiguous.

Suggested change

	|document| is a [=Document/fully active descendant of a top-level
	traversable with user attention=] and |gamepad| [=contains a gamepad
	user gesture=]:
	|document| is not `null` and is a [=Document/fully active descendant
	of a top-level traversable with user attention=] and |gamepad|
	[=contains a gamepad user gesture=]:

[marcoscaceres]

Ok, yeah... maybe this check should also happen earlier. If you don't have a document anyway, then none of the above really matters, right?

[Copilot]

This algorithm step is duplicated: Let |gamepads:sequence<Gamepad?>| be an empty list appears twice in a row. Remove the extra step to avoid confusion about variable re-declaration and keep the algorithm consistent.

Suggested change

	<li>Let |gamepads:sequence&lt;Gamepad?&gt;| be an empty [=list=].
	</li>

[gabrielsanbrito]

Should we create an alias for "focused"?

"A [=Document=] |document| is focused if |document| is a [=Document/fully active descendant of a top-level traversable with user attention=] and |gamepad| [=contains a gamepad user gesture=]:"?

[marcoscaceres]

I don’t think we should do that, to be honest. If we need the concept of focus, we should link out to HTML (which defines it).

[gabrielsanbrito]

Thinking about our current event model and the upcoming Input Events, should we also only dispatch events if the tab is focused?

[marcoscaceres]

If the document is null then that's exceptional... InvalidStateError?

[nondebug]

I think it doesn't make sense to throw here because we're inside "When the system receives new button or axis input values", if we throw an error there's nothing to catch it.

[marcoscaceres]

Ah, good point. Yes, it should just return gracefully.