Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

detectedPlanes throws exception, detection of feature availability is not graceful #30

Open
Maksims opened this issue Apr 7, 2021 · 1 comment

Comments

@Maksims
Copy link

Maksims commented Apr 7, 2021

Currently, it is possible to detect if the platform supports Plane Detection by checking the availability of XRPlane in window.
Once the session has started, and the first XRFrame is provided by XRSession, the only way to check if plane-detection feature is available, is to attempt to get detectedPlanes from XRFrame, and try/catch to identify if it is available.
Most other APIs have a better way to detect availability and do not follow try/catch pattern.

It would be more graceful if detectedPlanes would equal null if the feature is not available, instead of throwing an exception when checking the value of it. Especially while it is not a function, but a property.

Current approach (by the spec):

let planes;
try {
    planes = frame.detectedPlanes;
} catch(ex) {
    return;
}

Proposed approach:

const planes = frame.detectedPlanes;
if (planes === null)
    return;
@bialpio
Copy link
Contributor

bialpio commented Jun 17, 2021

I'm in process of changing it to make the behavior consistent with anchors API (i.e. frame.detectedPlanes will be initially empty & will get populated only when the frature is enabled). This unfortunately means that frame.detectedPlanes == null will not be something that could be used for feature availability & the apps will have no other option than using Permissions API for feature detection.

chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 21, 2021
OT feedback from plane detection API yielded a good point about
inconsistency between trackedAnchors and detectedPlanes behavior on an
XRFrame.

Changes:
- detectedPlanes should now behave the same way as trackedAnchors - they
will be empty even if the feature was not enabled on a session, feature
detection is not intended via those attributes
- clarified that anchorsData can be null coming from mojo & started
returning null when the feature is not enabled (same as OpenXR impl)
- null data coming from mojo for planes & anchors is treated as if the
data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_
basically short-circuits the logic that would've cleared them if
received data was empty)
- add WPT for anchors API to ensure that the frame's `trackedAnchors`
are empty irrespective of the feature status
- add internal WPT for anchors API to ensure that frame's
`trackedAnchors` are empty even if data coming from the device was null

Plane detection spec change still pending.

API feedback thread:
immersive-web/real-world-geometry#30

Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 22, 2021
OT feedback from plane detection API yielded a good point about
inconsistency between trackedAnchors and detectedPlanes behavior on an
XRFrame.

Changes:
- detectedPlanes should now behave the same way as trackedAnchors - they
will be empty even if the feature was not enabled on a session, feature
detection is not intended via those attributes
- clarified that anchorsData can be null coming from mojo & started
returning null when the feature is not enabled (same as OpenXR impl)
- null data coming from mojo for planes & anchors is treated as if the
data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_
basically short-circuits the logic that would've cleared them if
received data was empty)
- add WPT for anchors API to ensure that the frame's `trackedAnchors`
are empty irrespective of the feature status
- add internal WPT for anchors API to ensure that frame's
`trackedAnchors` are empty even if data coming from the device was null

Plane detection spec change still pending.

API feedback thread:
immersive-web/real-world-geometry#30

Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 22, 2021
OT feedback from plane detection API yielded a good point about
inconsistency between trackedAnchors and detectedPlanes behavior on an
XRFrame.

Changes:
- detectedPlanes should now behave the same way as trackedAnchors - they
will be empty even if the feature was not enabled on a session, feature
detection is not intended via those attributes
- clarified that anchorsData can be null coming from mojo & started
returning null when the feature is not enabled (same as OpenXR impl)
- null data coming from mojo for planes & anchors is treated as if the
data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_
basically short-circuits the logic that would've cleared them if
received data was empty)
- add WPT for anchors API to ensure that the frame's `trackedAnchors`
are empty irrespective of the feature status
- add internal WPT for anchors API to ensure that frame's
`trackedAnchors` are empty even if data coming from the device was null

Plane detection spec change still pending.

API feedback thread:
immersive-web/real-world-geometry#30

Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Piotr Bialecki <bialpio@chromium.org>
Cr-Commit-Position: refs/heads/master@{#894892}
chromium-wpt-export-bot pushed a commit to web-platform-tests/wpt that referenced this issue Jun 22, 2021
OT feedback from plane detection API yielded a good point about
inconsistency between trackedAnchors and detectedPlanes behavior on an
XRFrame.

Changes:
- detectedPlanes should now behave the same way as trackedAnchors - they
will be empty even if the feature was not enabled on a session, feature
detection is not intended via those attributes
- clarified that anchorsData can be null coming from mojo & started
returning null when the feature is not enabled (same as OpenXR impl)
- null data coming from mojo for planes & anchors is treated as if the
data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_
basically short-circuits the logic that would've cleared them if
received data was empty)
- add WPT for anchors API to ensure that the frame's `trackedAnchors`
are empty irrespective of the feature status
- add internal WPT for anchors API to ensure that frame's
`trackedAnchors` are empty even if data coming from the device was null

Plane detection spec change still pending.

API feedback thread:
immersive-web/real-world-geometry#30

Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Piotr Bialecki <bialpio@chromium.org>
Cr-Commit-Position: refs/heads/master@{#894892}
blueboxd pushed a commit to blueboxd/chromium-legacy that referenced this issue Jun 23, 2021
OT feedback from plane detection API yielded a good point about
inconsistency between trackedAnchors and detectedPlanes behavior on an
XRFrame.

Changes:
- detectedPlanes should now behave the same way as trackedAnchors - they
will be empty even if the feature was not enabled on a session, feature
detection is not intended via those attributes
- clarified that anchorsData can be null coming from mojo & started
returning null when the feature is not enabled (same as OpenXR impl)
- null data coming from mojo for planes & anchors is treated as if the
data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_
basically short-circuits the logic that would've cleared them if
received data was empty)
- add WPT for anchors API to ensure that the frame's `trackedAnchors`
are empty irrespective of the feature status
- add internal WPT for anchors API to ensure that frame's
`trackedAnchors` are empty even if data coming from the device was null

Plane detection spec change still pending.

API feedback thread:
immersive-web/real-world-geometry#30

Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Piotr Bialecki <bialpio@chromium.org>
Cr-Commit-Position: refs/heads/master@{#894892}
moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Jun 27, 2021
…ors & detectedPlanes, a=testonly

Automatic update from web-platform-tests
WebXR: align the behavior of trackedAnchors & detectedPlanes

OT feedback from plane detection API yielded a good point about
inconsistency between trackedAnchors and detectedPlanes behavior on an
XRFrame.

Changes:
- detectedPlanes should now behave the same way as trackedAnchors - they
will be empty even if the feature was not enabled on a session, feature
detection is not intended via those attributes
- clarified that anchorsData can be null coming from mojo & started
returning null when the feature is not enabled (same as OpenXR impl)
- null data coming from mojo for planes & anchors is treated as if the
data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_
basically short-circuits the logic that would've cleared them if
received data was empty)
- add WPT for anchors API to ensure that the frame's `trackedAnchors`
are empty irrespective of the feature status
- add internal WPT for anchors API to ensure that frame's
`trackedAnchors` are empty even if data coming from the device was null

Plane detection spec change still pending.

API feedback thread:
immersive-web/real-world-geometry#30

Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Piotr Bialecki <bialpio@chromium.org>
Cr-Commit-Position: refs/heads/master@{#894892}

--

wpt-commits: e6036168a8a3142188cdbe31aa4ca3a9da09ffb0
wpt-pr: 29445
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Jul 16, 2021
…ors & detectedPlanes, a=testonly

Automatic update from web-platform-tests
WebXR: align the behavior of trackedAnchors & detectedPlanes

OT feedback from plane detection API yielded a good point about
inconsistency between trackedAnchors and detectedPlanes behavior on an
XRFrame.

Changes:
- detectedPlanes should now behave the same way as trackedAnchors - they
will be empty even if the feature was not enabled on a session, feature
detection is not intended via those attributes
- clarified that anchorsData can be null coming from mojo & started
returning null when the feature is not enabled (same as OpenXR impl)
- null data coming from mojo for planes & anchors is treated as if the
data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_
basically short-circuits the logic that would've cleared them if
received data was empty)
- add WPT for anchors API to ensure that the frame's `trackedAnchors`
are empty irrespective of the feature status
- add internal WPT for anchors API to ensure that frame's
`trackedAnchors` are empty even if data coming from the device was null

Plane detection spec change still pending.

API feedback thread:
immersive-web/real-world-geometry#30

Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Piotr Bialecki <bialpio@chromium.org>
Cr-Commit-Position: refs/heads/master@{#894892}

--

wpt-commits: e6036168a8a3142188cdbe31aa4ca3a9da09ffb0
wpt-pr: 29445
mjfroman pushed a commit to mjfroman/moz-libwebrtc-third-party that referenced this issue Oct 14, 2022
OT feedback from plane detection API yielded a good point about
inconsistency between trackedAnchors and detectedPlanes behavior on an
XRFrame.

Changes:
- detectedPlanes should now behave the same way as trackedAnchors - they
will be empty even if the feature was not enabled on a session, feature
detection is not intended via those attributes
- clarified that anchorsData can be null coming from mojo & started
returning null when the feature is not enabled (same as OpenXR impl)
- null data coming from mojo for planes & anchors is treated as if the
data was empty (clearing the plane_ids_to_planes_ / anchor_ids_to_anchors_
basically short-circuits the logic that would've cleared them if
received data was empty)
- add WPT for anchors API to ensure that the frame's `trackedAnchors`
are empty irrespective of the feature status
- add internal WPT for anchors API to ensure that frame's
`trackedAnchors` are empty even if data coming from the device was null

Plane detection spec change still pending.

API feedback thread:
immersive-web/real-world-geometry#30

Change-Id: Iab52176dba08df3cb64c7e581a5f6790cd4b19bb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2973587
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Piotr Bialecki <bialpio@chromium.org>
Cr-Commit-Position: refs/heads/master@{#894892}
NOKEYCHECK=True
GitOrigin-RevId: a91618bd1ef01173aac3e018f8c5f3429fd031e5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants