Enhance Gamepad interface description for Touch #168

bradleyneedham · 2022-07-19T21:33:49Z

Closes #167

The following tasks have been completed:

Modified Web platform tests (link to pull request)

Implementation commitment:

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

Standards positions:

Resources:

Explainer (https://github.com/bradleyneedham/gamepad/blob/multitouch-explainer/multitouch_explainer.md)
Gamepad Tests (https://github.com/bradleyneedham/gamepadtest)
Tag Review (Gamepad Extensions API touch input w3ctag/design-reviews#799)

siusin · 2022-07-20T12:24:16Z

@bradleyneedham could you associate your GitHub account with your W3C account, please? It will help to resolve the IRP issue. Thank you.

bradleyneedham · 2022-07-20T16:19:47Z

Absolutely would if I had one :-). Does this work better if @sagoston submits the changes?
Signed up for an account. No email to confirm yet. Will update here once resolved.

bradleyneedham · 2022-07-20T17:40:07Z

Ok, done, GitHub account should now be associated with my W3C account.

siusin · 2022-07-21T13:18:25Z

@bradleyneedham

Excellent, thank you! The editors are expected to review this pull request and merge it when ready.

nondebug · 2022-07-22T23:44:16Z

extensions.html

+              device max x-axis coordinate.
+              </li>
+              <li>Set |touchEvent|.{{GamepadTouch/surfaceDimensions}}[1] to be
+              device max y-axis coordinate.<p>(<i>note: surfaceDimensions can be set to `null`</i>)</p>


Please rewrite these steps with a branch where surfaceDimensions is set to null. We can leave "why is it null?" up to the browser implementer, but if we don't have steps where it can be set to null then it should never be null.

It should be something like:

If the touch surface exposes maximum surface dimensions in device units:

Set touchEvent.surfaceDimensions[0] to ...

Set touchEvent.surfaceDimensions[1] to ...

Otherwise:

Set touchEvent.surfaceDimensions to null

This may need more discussion. Perhaps there is not a case where surfaceDimensions can be null. For the DS4 touch coordinates are normalized using the device touch point and the surface dimensions. Should the algorithm include receiving input from a device that sends already normalized touch points and does not report surface dimensions?

nondebug · 2022-07-22T23:55:27Z

extensions.html

+              <li>Set |touchEvent|.{{GamepadTouch/surfaceDimensions}}[1] to be
+              device max y-axis coordinate.<p>(<i>note: surfaceDimensions can be set to `null`</i>)</p>
+              </li>
+              <li>Add |touchEvent| to |gamepad|.{{Gamepad/[[touchEvents]]}}.


We're adding to the touchEvents internal slot but never remove from it. This algorithm should start by emptying touchEvents since we plan to replace the whole list each time we update.

Added step to empty out any existing events from touchEvents.

nondebug · 2022-07-23T00:02:37Z

extensions.html

+              `touchData.touchID`.
+              </li>
+              <li>Set |touchEvent|.{{GamepadTouch/surfaceId}} to be
+              device surfaceId.


It's unclear where the device surfaceId comes from. I think it would be simpler to specify it as an index into whatever the surface ordering happens to be:

Let surfaceId be 0

For each touch surface:

For each touch input on that surface:

Create and add the touch event (with surfaceId)

Increment surfaceId

Added outer loop to iterate surfaces.

nondebug · 2022-07-23T00:18:38Z

extensions.html

+              <li>Let |touchEvent:GamepadTouch| be a {{GamepadTouch}}.
+              </li>
+              <li>Set |touchEvent|.{{GamepadTouch/touchId}} to be
+              `touchData.touchID`.


We need to specify more of how the touch event's touchID is initialized since it's important for how applications will interact with the API. Let's try to leverage the Touch Events specification which already defines "active touch point":

https://w3c.github.io/touch-events/#dfn-active-touch-point

If the touch data is part of an existing [=active touch point=] tracked by the user agent:

Set touchID to the touchID of the active touch point

Otherwise, set touchID to nextTouchID and increment nextTouchID

nextTouchID should be a Gamepad internal slot so it's always unique even when there are multiple touch surfaces on the same gamepad.

@nondebug I manually added the link, it appears that the dfn is not exported (or possibly, probably, I am not using xref correctly). I am also a little concerned that we are making the spec too restrictive to implementers, e.g. I am working on the DS4 GamepadTouch implementation in chromium and find that normalizing the touchId is much easier at the ds4_controller than the device/gamepad (this may be a bad assumption on my part that when you refer to an "internal slot" it would translate to that object). Requiring the nextTouchId in device/gamepad might cause difficulty in implementing other touch controllers. The specification just needs to be clear that implementers support 32 bit value starting at 0 and incrementing with each new touch event not associated with an existing active touch point. How this is accomplished should be open.
I will try and add some "Usage Examples" to better explain how applications will interact with the API.

it appears that the dfn is not exported

I'm not sure why the xref dfn doesn't work. It doesn't show up in https://respec.org/xref/ either. https://respec.org/docs/#xref suggests it needs a change to the touch-events spec to export it. I'm okay with leaving it as-is for now, we can clean this up later when the extension is merged into the main specification.

normalizing the touchId is much easier at the ds4_controller than the device/gamepad (this may be a bad assumption on my part that when you refer to an "internal slot" it would translate to that object)

Normalizing touchId in Dualshock4Controller won't work because a device::Gamepad isn't 1-to-1 with a blink::Gamepad. Most of the time, "internal slot" should be read as "1-to-1 with blink::Gamepad". The only time we can attach internal slots to device::Gamepad is if all tabs should see the same value. This isn't true for touchId and nextTouchId since they may differ between tabs even for the same gamepad.

Suppose there's a tab accessing a DS4 through Gamepad API and it receives a touch point with ID 0. Then a second tab is opened and begins accessing DS4 through Gamepad API. When the next touch occurs, the first tab should get a touch point with ID 1 and the second tab should get touch ID 0. If we deliver touch ID 1 to both tabs then the second tab can deduce that another tab was accessing Gamepad API.

We can store raw touchIds in the device::Gamepad buffer and normalize them in blink::Gamepad::UpdateFromDeviceState. To normalize the ID, blink::Gamepad will need to maintain nextTouchId along with a mapping from raw->normalized touchIds for all active touch points. The rest of the touch data (surfaceId, position, surfaceDimensions) won't change between tabs so we can store it in the device::Gamepad buffer.

Requiring the nextTouchId in device/gamepad might cause difficulty in implementing other touch controllers. The specification just needs to be clear that implementers support 32 bit value starting at 0 and incrementing with each new touch event not associated with an existing active touch point. How this is accomplished should be open.

Agreed, the spec should not care how active touch points are identified. We only need to be able to enumerate them and somehow associate current set of active touch points with the set of active touch points from the previous update.

nondebug · 2022-07-23T00:26:58Z

extensions.html

        </dd>
        <dt>
          <dfn>touchEvents</dfn>
        </dt>
        <dd>
          A list of touch events generated from all touch surfaces.
-          <code>null</code> if the device does not support touch events.
+          If the device does not support touch events, MUST be set to `null`.


touchEvents should define a getter algorithm that returns the data from the internal slot.

nondebug · 2022-07-23T00:49:42Z

extensions.html

+        <p>
+          In addtion to the steps defined in the main 
+          <a href="https://w3c.github.io/gamepad/">Gamepad specification</a>.
+          When the system receives new touch input values,


When the system receives new touch input values,

This seems ambiguous to me, it's unclear whether "new touch input values" includes updates where there are no touches, for example a DS4 input report that doesn't contain any active touch points. We want this method to run for every DS4 input report, even when there are no active touch points.

Perhaps something like:

"When the user agent modifies the list of [=active touch points=] for a touch surface by adding touch points, removing touch points, or updating the values of existing touch points, update touchEvents by running the following steps:"

nondebug · 2022-07-23T01:08:00Z

extensions.html

+        <ol>
+          <li>Let |gamepad:Gamepad| be a newly created {{Gamepad}} instance:
+            <ol>
+              <li>Initialize |gamepad|'s {{Gamepad/touchEvents}} to the result of


I think here we should initialize the touchEvents internal slot to an empty list if the gamepad has any touch surfaces, otherwise null. The [=updating touchEvents=] algorithm will be called automatically whenever the first touch inputs are received so we don't need to call it here.

The actual touchEvents attribute (not the internal slot) should define a getter algorithm that returns the data from the internal slot. That way the attribute is initialized when we initialize the internal slot. We use the internal slot because the attribute is readonly so technically it has no setter but we still need a way to update it.

nondebug · 2022-08-09T00:24:46Z

extensions.html

+              <li>Let |touchEvent:GamepadTouch| be a {{GamepadTouch}}.
+              </li>
+              <li>Set |touchEvent|.{{GamepadTouch/touchId}} to be
+              `touchData.touchID`.


it appears that the dfn is not exported

I'm not sure why the xref dfn doesn't work. It doesn't show up in https://respec.org/xref/ either. https://respec.org/docs/#xref suggests it needs a change to the touch-events spec to export it. I'm okay with leaving it as-is for now, we can clean this up later when the extension is merged into the main specification.

normalizing the touchId is much easier at the ds4_controller than the device/gamepad (this may be a bad assumption on my part that when you refer to an "internal slot" it would translate to that object)

Normalizing touchId in Dualshock4Controller won't work because a device::Gamepad isn't 1-to-1 with a blink::Gamepad. Most of the time, "internal slot" should be read as "1-to-1 with blink::Gamepad". The only time we can attach internal slots to device::Gamepad is if all tabs should see the same value. This isn't true for touchId and nextTouchId since they may differ between tabs even for the same gamepad.

Suppose there's a tab accessing a DS4 through Gamepad API and it receives a touch point with ID 0. Then a second tab is opened and begins accessing DS4 through Gamepad API. When the next touch occurs, the first tab should get a touch point with ID 1 and the second tab should get touch ID 0. If we deliver touch ID 1 to both tabs then the second tab can deduce that another tab was accessing Gamepad API.

We can store raw touchIds in the device::Gamepad buffer and normalize them in blink::Gamepad::UpdateFromDeviceState. To normalize the ID, blink::Gamepad will need to maintain nextTouchId along with a mapping from raw->normalized touchIds for all active touch points. The rest of the touch data (surfaceId, position, surfaceDimensions) won't change between tabs so we can store it in the device::Gamepad buffer.

Requiring the nextTouchId in device/gamepad might cause difficulty in implementing other touch controllers. The specification just needs to be clear that implementers support 32 bit value starting at 0 and incrementing with each new touch event not associated with an existing active touch point. How this is accomplished should be open.

Agreed, the spec should not care how active touch points are identified. We only need to be able to enumerate them and somehow associate current set of active touch points with the set of active touch points from the previous update.

nondebug · 2022-08-09T01:39:00Z

extensions.html

+        <ol>
+          <li>Let |surfaceId:unsigned long| be 0.
+          </li>
+          <li>Let |touchSurfaces:list| be an [=ordered set=] of touch surfaces


In this algorithm we describe touchSurfaces, touchInputs, touchData but there's no instructions on how to construct those objects.

We want to emphasize the assumptions we're making about the inputs but we also don't want to specify more than we have to. I think we can modify the algorithm to be more specific about the assumptions we're making while being less specific about how the data is presented. For example, if we specify that a gamepad's touch surfaces need to have some consistent ordering then we can iterate over them without creating lists:

Let |surfaceId| be 0.

Repeat these steps for each [=touch surface=] on |gamepad| in [=touch surface enumeration order=]:

Let |surfaceDimensions| be null.

If the [=touch surface=] exposes maximum dimensions in device units:

Set |surfaceDimensions| to a [=new=] {{Array}} with length 2.

Set |surfaceDimensions|[0] to the maximum X dimension of the current [=touch surface=] in device units.

Set |surfaceDimensions|[1] to the maximum Y dimension of the current [=touch surface=] in device units.

Repeat these steps for each [=active touch point=] on the current [=touch surface=]:

Let |x:float| be the X coordinate for the current [=active touch point=] in device units.

Let |y:float| be the Y coordinate for the current [=active touch point=] in device units.

Let |position| be a [=new=] {{Array}} with length 2.

If |surfaceDimensions| is null:

Set |position|[0] to ???.

Set |position|[1] to ???.

Otherwise:

Set |position|[0] to a value calculated from |x| and |surfaceDimensions|[0] and normalized to [-1,1].

Set |position|[1] to a value calculated from |y| and |surfaceDimensions|[1] and normalized to [-1,1].

Let |touchEvent| be a [=new=] {{GamepadTouch}}:

Initialize |touchEvent|.{{GamepadTouch/surfaceId}} to |surfaceId|.

Initialize |touchEvent|.{{GamepadTouch/position}} to |position|.

Initialize |touchEvent|.{{GamepadTouch/surfaceDimensions}} to |surfaceDimensions|.

[=list/Append=] |touchEvent| to |gamepad|.{{Gamepad/[[touchEvents]]}}.

Increment |surfaceId|.

Normalizing touchId in Dualshock4Controller won't work because a device::Gamepad isn't 1-to-1 with a blink::Gamepad. Most of the time, "internal slot" should be read as "1-to-1 with blink::Gamepad". The only time we can attach internal slots to device::Gamepad is if all tabs should see the same value. This isn't true for touchId and nextTouchId since they may differ between tabs even for the same gamepad.

I went back and double checked and what I have observed is that the lifetime of a blink::Gamepad is very short maybe each render, so will not work for touchId and nextTouchId. This is probably not the forum for this discussion (I need to figure out how to start it over on the chromium site).
This does create an issue with implementing the specification since the lifetime of the device::Gamepad is not correct either as you point out.

We want to emphasize the assumptions we're making about the inputs but we also don't want to specify more than we have to. I think we can modify the algorithm to be more specific about the assumptions we're making while being less specific about how the data is presented. For example, if we specify that a gamepad's touch surfaces need to have some consistent ordering then we can iterate over them without creating lists:

Agreed, I will work on addressing this.

Ah right, blink::Gamepad is short-lived. The specification says it should behave like a live object but the Chromium implementation hasn't been updated to match that behavior yet. (Relevant spec issue: #8)

We've worked around this by attaching the internal state to blink::NavigatorGamepad instead of blink::Gamepad and creating a Gamepad::Client interface to provide access to this internal state so it's persisted even when the blink::Gamepad is destroyed and recreated.

This is probably not the forum for this discussion (I need to figure out how to start it over on the chromium site).

Let's use this crbug to discuss the Chromium implementation: 1143942: Gamepad Multitouch

@nondebug I have restructured the Receiving inputs section and added a Glossary for terms. Several updates to your other comments we made a bit back, should I just resolve those comments?
There is a suggestion at the top "Still in progress? Convert to draft", does that make since?

nondebug

The extensions.html content looks good to me, I think this can be merged once the formatting issues are fixed.

extensions.html

nondebug · 2022-12-12T22:33:16Z

extensions.html

@@ -50,7 +50,7 @@
                company: "Google", companyURL: "http://www.google.com/",
                w3cid: 87824 },
          ],
-
+          xref: true,


Please remove this xref in favor of the xref below with a list of specification short names.

nondebug

lgtm

marcoscaceres · 2022-12-20T23:09:10Z

@bradleyneedham, would you mind rebasing so it's easier to review?

bradleyneedham · 2022-12-21T19:28:44Z

Hi @marcoscaceres, took me a little but I think I got the rebase correct. This will hopefully be easier to see the changes.

marcoscaceres · 2023-02-17T03:30:14Z

extensions.html

+          "updating touchEvents">update touchEvents</dfn> by running the
+          following steps:
+        </p>
+        <ol>


Suggested change

<ol>

<ol class="algorithm">

marcoscaceres · 2023-02-17T03:31:25Z

extensions.html

+            <dfn data-dfn-for="Gamepad">[[\touchEvents]]</dfn>
+          </td>
+          <td>
+            <code>null</code>


Suggested change

<code>null</code>

`null`

I wonder if this should initially just be an empty list? Then we don't need to deal with list and null as types

I think because not all Gamepads support touch pads, it is better this way to distinguish between a Gamepad that will never have touchIds (null) and a Gamepad that just has no new input (empty list).

marcoscaceres · 2023-02-17T03:34:11Z

extensions.html

+        </dt>
+        <dd>
+          An enumeration that indicates which hand the controller is being held
+          in or is most likely to be held in. `"left"`, `"right"`, or `""`.


Would "both" be better than ""?

The enumeration is better described above in the document. I changed this to refer to the above definition. I think "" can mean "both", "either", or "NA", and perhaps it only matters to the developer if it is "left" or "right".
Perhaps @nondebug has more insight.

Changes and updates have been made to Fernando Attia's patchset 1612050. The implementation has been changed to support the most recent changes to the spec w3c/gamepad#168. Support for DualShock4 controller is part of patch. This commit is a squash of several changes the last major one is: Normalize touchIds per Gamepad The same hardware may provide input to Gamepads in different tabs. This commit normalizes touchIds coming from the hardware to a single incremented value starting at zero per Gamepad instance. Extend the Gamepad API to support multitouch surfaces (touchpads). Intent to prototype : https://groups.google.com/a/chromium.org/g/blink-dev/c/4q_k23rPMos Chrome status entry: https://www.chromestatus.com/feature/4782975812108288 R=mattreynolds@chromium.org Change-Id: I0fa2006c3fc36a908b316cc29b97d295aac798ca Update idl to match current spec draft Normalize touchid to 32bit value. Update web tests. Bug: 1143942 Change-Id: I80ed31ebf0c6a347906b91b3c178099d1e332c53

Changes and updates have been made to Fernando Attia's patchset 1612050. The implementation has been changed to support the most recent changes to the spec w3c/gamepad#168. Support for DualShock4 controller is part of patch. This commit is a squash of several changes the last major one is: Normalize touchIds per Gamepad The same hardware may provide input to Gamepads in different tabs. This commit normalizes touchIds coming from the hardware to a single incremented value starting at zero per Gamepad instance. Extend the Gamepad API to support multitouch surfaces (touchpads). Intent to prototype : https://groups.google.com/a/chromium.org/g/blink-dev/c/4q_k23rPMos Chrome status entry: https://www.chromestatus.com/feature/4782975812108288 R=mattreynolds@chromium.org Change-Id: I0fa2006c3fc36a908b316cc29b97d295aac798ca Update idl to match current spec draft Normalize touchid to 32bit value. Update web tests. Bug: 1143942 Change-Id: I80ed31ebf0c6a347906b91b3c178099d1e332c53 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3866373 Reviewed-by: Matt Reynolds <mattreynolds@chromium.org> Commit-Queue: Matt Reynolds <mattreynolds@chromium.org> Cr-Commit-Position: refs/heads/main@{#1126297}

…=testonly Automatic update from web-platform-tests Add multitouch support to Gamepad API Changes and updates have been made to Fernando Attia's patchset 1612050. The implementation has been changed to support the most recent changes to the spec w3c/gamepad#168. Support for DualShock4 controller is part of patch. This commit is a squash of several changes the last major one is: Normalize touchIds per Gamepad The same hardware may provide input to Gamepads in different tabs. This commit normalizes touchIds coming from the hardware to a single incremented value starting at zero per Gamepad instance. Extend the Gamepad API to support multitouch surfaces (touchpads). Intent to prototype : https://groups.google.com/a/chromium.org/g/blink-dev/c/4q_k23rPMos Chrome status entry: https://www.chromestatus.com/feature/4782975812108288 R=mattreynolds@chromium.org Change-Id: I0fa2006c3fc36a908b316cc29b97d295aac798ca Update idl to match current spec draft Normalize touchid to 32bit value. Update web tests. Bug: 1143942 Change-Id: I80ed31ebf0c6a347906b91b3c178099d1e332c53 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3866373 Reviewed-by: Matt Reynolds <mattreynolds@chromium.org> Commit-Queue: Matt Reynolds <mattreynolds@chromium.org> Cr-Commit-Position: refs/heads/main@{#1126297} -- wpt-commits: c03609e36f4e7d3ad8888b7532650836fc1bc7ef wpt-pr: 39227

Move to a different branch

Other small formatting updates

bradleyneedham · 2023-05-05T21:45:47Z

@nondebug @sagoston @marcoscaceres Thank you all again for your review and comments.
I rebased this, it still looks good to merge, the error that is now showing is in "index.html" not a file I changed. Let me know if there is something else I need to fix.

bradleyneedham · 2023-07-14T00:28:45Z

@marcoscaceres I have added links to the explainer, tests, and standards positions in the first comment. Thank you again for your time and consideration.

bradleyneedham · 2023-08-21T17:42:48Z

Hi @nondebug, the failure I am getting here is the same as the failure that #172 is getting.
It has to do with the reference to [="xr-standard" gamepad mapping=] on line 1023-1024 of index.html.
The reference appears to be correct but the test does not appear to like it.

nondebug · 2023-08-21T23:07:58Z

Relevant error message:

Error: ROR] Couldn’t find “"xr-standard" gamepad mapping“ in this document or other cited documents: [dom], [hr-time], [html], [infra], [permissions-policy], [webidl], and [webxr-gamepads-module].

I'm not sure why that reference fails, it appears to be correct according to the xref tool:

https://respec.org/xref/?term=%22xr-standard%22+gamepad+mapping

@marcoscaceres can you take a look?

dontcallmedom · 2023-09-12T16:19:45Z

extensions.html

@@ -95,8 +95,7 @@
          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
          // Team Contact.
          wgPatentURI:  "https://www.w3.org/2004/01/pp-impl/83482/status",
-
-          xref: ["DOM", "HTML", "INFRA", "gamepad"],
+          xref: ["HTML", "DOM", "PERMISSIONS-POLICY", "HR-TIME", "INFRA", "gamepad"],


Suggested change

xref: ["HTML", "DOM", "PERMISSIONS-POLICY", "HR-TIME", "INFRA", "gamepad"],

xref: ["HTML", "DOM", "PERMISSIONS-POLICY", "HR-TIME", "INFRA", "gamepad","webxr-gamepads-module"],

This should solve the ReSpec/xref issue

I think that's not sufficient to solve the issue. The failure is in index.html in a part of the document not modified by the PR, so I suspect it was a change in respec that caused this failure.

@marcoscaceres said it looks like a respec bug. The xref sees " instead of double-quote characters so it fails to match against the webxr-gamepads-module reference.

nondebug self-assigned this Jul 20, 2022

nondebug reviewed Jul 23, 2022

View reviewed changes

nondebug reviewed Aug 9, 2022

View reviewed changes

nondebug reviewed Dec 12, 2022

View reviewed changes

nondebug approved these changes Dec 12, 2022

View reviewed changes

bradleyneedham mentioned this pull request Dec 14, 2022

Gamepad Extensions API touch input w3ctag/design-reviews#799

Closed

bradleyneedham force-pushed the gh-pages branch from b6f4fc7 to e8b34cb Compare December 21, 2022 19:21

marcoscaceres reviewed Feb 17, 2023

View reviewed changes

bradleyneedham force-pushed the gh-pages branch from e8b34cb to 24ff5fe Compare February 21, 2023 21:05

chromium-wpt-export-bot mentioned this pull request Mar 27, 2023

Add multitouch support to Gamepad API web-platform-tests/wpt#39227

Merged

bradleyneedham added 2 commits May 5, 2023 14:20

Enhance Gamepad interface description for Touch

115afbd

Add branch where surfaceDimensions is set to null.

41f86b3

bradleyneedham and others added 13 commits May 5, 2023 14:20

Add step to remove events from gamepad.touchEvents

ceb63de

Add outer loop for multiple surfaces

9a8dc18

Reword when "update touchEvents" should occur.

c9d3302

Add getter algorithm

8fe5ed0

Update initialization of touchEvents.

218799f

Included [active touch point] to set touchId

69a415e

Restructure of Receiving inputs section.

3a9b4de

Create multitouch_explainer.md

f451bfb

Update multitouch_explainer.md

96aec0a

Delete multitouch_explainer.md

5188615

Move to a different branch

Apply tidy to clean up HTML format

464c237

Remove "xref: true"

8c2e295

Specify touchId requires unique ids per origin

3947b1e

Other small formatting updates

bradleyneedham force-pushed the gh-pages branch from 8670954 to 3947b1e Compare May 5, 2023 21:23

marcoscaceres self-requested a review July 13, 2023 23:13

Update extensions.html

427ff97

nondebug mentioned this pull request Sep 12, 2023

xref for "xr-standard" gamepad mapping not working speced/respec#4535

Closed

dontcallmedom reviewed Sep 12, 2023

View reviewed changes

Update extensions.html

75761be

nondebug mentioned this pull request Sep 13, 2023

"TypeError: handle.executionContext is not a function" at respecDocWriter.js:308 speced/respec#4538

Closed

Update extensions.html

ce87f1a

nondebug merged commit 7a89897 into w3c:gh-pages Oct 5, 2023
2 checks passed

	xref: ["HTML", "DOM", "PERMISSIONS-POLICY", "HR-TIME", "INFRA", "gamepad"],
	xref: ["HTML", "DOM", "PERMISSIONS-POLICY", "HR-TIME", "INFRA", "gamepad","webxr-gamepads-module"],

Enhance Gamepad interface description for Touch #168

Enhance Gamepad interface description for Touch #168

Conversation

bradleyneedham commented Jul 19, 2022 • edited Loading

siusin commented Jul 20, 2022

bradleyneedham commented Jul 20, 2022 • edited Loading

bradleyneedham commented Jul 20, 2022

siusin commented Jul 21, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nondebug left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nondebug left a comment

Choose a reason for hiding this comment

marcoscaceres commented Dec 20, 2022

bradleyneedham commented Dec 21, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

marcoscaceres Feb 17, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bradleyneedham commented May 5, 2023 • edited Loading

bradleyneedham commented Jul 14, 2023

bradleyneedham commented Aug 21, 2023

nondebug commented Aug 21, 2023

Choose a reason for hiding this comment

nondebug Sep 12, 2023 • edited Loading

Choose a reason for hiding this comment

bradleyneedham commented Jul 19, 2022 •

edited

Loading

bradleyneedham commented Jul 20, 2022 •

edited

Loading

marcoscaceres Feb 17, 2023 •

edited

Loading

bradleyneedham commented May 5, 2023 •

edited

Loading

nondebug Sep 12, 2023 •

edited

Loading