Intent to Ship: WebXr hand input module - Level 1

[Alex Cooper]

Contact emails

alco...@chromium.org

Explainer

https://github.com/immersive-web/webxr-hand-input/blob/main/explainer.md

Specification

https://immersive-web.github.io/webxr-hand-input

Summary

Exposes hand joint data on XrInputSources for use during a WebXr session. This allows developers to have more fine grained interactions during WebXr sessions.

Blink component

Blink>WebXR

TAG review

https://github.com/w3ctag/design-reviews/issues/568

TAG review status

Issues addressed

Risks

Interoperability and Compatibility

None

Gecko: No signal

WebKit: Shipped/Shipping (https://webkit.org/blog/15443/news-from-wwdc24-webkit-in-safari-18-beta)

Web developers: Strongly positive

Other signals: Shipped on Meta Quest, Initially added to Chrome for HoloLens support

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None

Debuggability

None

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

WebXR is only supported on Windows and Android (not WebView)

Is this feature fully tested by web-platform-tests?

No

API shape is relatively simple consisting largely of the enum and a simple idl to get a "joint space", which is used in other tested APIs; however, generating realistic synthetic joint data (~50 poses) is quite difficult and error prone. Further, no test API currently exists to supply this data. https://github.com/immersive-web/webxr-test-api/issues/86 tracks investigating adding such an API. IDL validation: https://wpt.fyi/results/webxr/hand-input?label=experimental&label=master&aligned

Flag name on chrome://flags

webxr-hand-input

Finch feature name

WebXRHandInput

Requires code in //chrome?

False

Tracking bug

https://crbug.com/359418633

Launch bug

https://launch.corp.google.com/launch/4338213

Sample links

https://immersive-web.github.io/webxr-samples/immersive-hands.html

Estimated milestones

Shipping on desktop	130
Shipping on Android	130

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6290425179275264?gate=6298185765748736

Links to previous Intent discussions

Intent to Prototype: https://groups.google.com/a/chromium.org/forum

This intent message was generated by Chrome Platform Status.

[Rik Cabanier]

Awesome to hear to see this shipping on Chrome!

Quest browser has supported this API for close to 4 years and it's used by many developers and supported by all WebXR frameworks.

Does your implementation ensure that the hand joints are not matched to the user? 

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGOLbz0GZkKBz1Zma9aEdkJj8GMXcLx0nnXbOyKbKG%2BXn37tcw%40mail.gmail.com.

[Alex Cooper]

Thanks Rik,

Good catch! The actual impl here is fairly old and I assumed this was something the underlying API already handled. My recent work on the feature has largely been integrating with our permissions framework and the launch process. This CL addresses the issue. I think it should land in time for M130, but if not, I won't enable the feature until it does land.

[Daniel Clark]

Any reason not to request a Gecko position on this? Per https://mozilla.github.io/standards-positions/#webxr they’re Positive on WebXR in general but I don’t think that necessarily implies support for the modules like this one, so it might be good to ask about this specifically.

Thanks,

Dan

From: Alex Cooper <alco...@chromium.org>
Date: Thursday, September 12, 2024 at 3:26 PM
To: Rik Cabanier <caba...@gmail.com>
Cc: blink-dev <blin...@chromium.org>
Subject: Re: [blink-dev] Intent to Ship: WebXr hand input module - Level 1

You don't often get email from alco...@chromium.org. Learn why this is important

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGOLbz0_yujuwxwQTYeqHdA4h8ngVmvygceqoZAnEnKazXkmYw%40mail.gmail.com.

[Alex Cooper]

To be honest, I didn't feel it was necessary given that the specification was already shipped in Safari and on Quest (which admittedly is a Chromium fork), and my understanding was that Mozilla was not making active investments into any WebXR efforts. However, I've gone ahead and filed a standards position request for mozilla here: https://github.com/mozilla/standards-positions/issues/1070

And to head off any future request, I've also filed the WebKit one, though I assume it's mainly a formality given that it's shipping on the Apple Vision Pro: https://github.com/WebKit/standards-positions/issues/395

[Mike Taylor]

Thanks for requesting the positions - it seems fair to me to give Mozilla at least a week to respond (and looks like WebKit intends to give a formal "support" response).

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAGOLbz3DHRMDSBrx4S4bm4jxPEQBnDh73296y%3D3_38gZ3AfT7A%40mail.gmail.com.

[Chris Harrelson]

LGTM1

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/278069f7-e565-4de9-9760-97b9c8187cd2%40chromium.org.

[Vladimir Levin]

Just to confirm, the access to the information provided by this API is gated by the "hand-tracking" requestSession permission. Is that correct?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_C_1zEBKFD83JwCxk1wLh8Bqje-mrcWZdYQ9-N0dt5ww%40mail.gmail.com.

[Alex Cooper]

The feature is not considered for enablement in WebXR (and no information is exposed) unless the site requests the "hand-tracking" feature as part of requestSession. However, that is separate from the concept of permissions. There *is* a separate chrome permission for hand tracking that is checked when the site requests this feature, and depending on if the feature was requested as "Required" or "Optional" the site will either not get a WebXR session or will get a WebXR session without that feature enabled if the permission is rejected by the user.

[Vladimir Levin]

Got it, thanks for the explanation.

LGTM2

[Mike Taylor]

LGTM3