I am trying to use XR viewer to do development for WebXR and three js. When I start a local host HTTPS server for development I can connect on chrome by going to https://<ip>:<port>, but the XR viewer on iOS cannot open the page. currently I have been having to push every change to GitHub pages and it makes the development process really slow. Is this a known issue? is there anyway to get around this to use XR viewer to access a locally hosted dev instance?

To reproduce:

• Open https://modelviewer.dev/examples/augmented-reality.html
• Select ... menu and "Request Mobile Site"
• Click the little AR button

Expected: Apple's Quick Look opens with the USDZ file
Actual: Firefox downloads the USDZ file

Quick Look is picky about the mime type which is probably incorrect here.

Currently, the session is "not immersive". But, full-screen AR on a mobile phone is considered "immersive" in the docs. From section 5.1 of https://immersive-web.github.io/webxr/#xrsessioncreationoptions-interface:

A session is considered to be an immersive session if it’s output is displayed to the user in a way that makes the user feel the content is present in the same space with them, shown at the proper scale. Sessions are considered non-immersive (sometimes referred to as inline) if their output is displayed as an element in an HTML document.

Essentially, "immersive" means "fullscreen 3D AR/VR" and "non immersive" means "get sensor data and somehow render in a canvas inside the html page"

Three.js WebXR AR examples don't recognize our AR capability. When the application starts up Three.js ARButton checks navigator.xr but at that time it seems navigator.xr isn't defined yet.

Android Chrome (native WebXR API) and WebXR Emulator Extension work fine. So maybe there is something problem in our side.

We've updated our polyfill to support the newest WebXR API, and also updated the examples listed in splash.html other than Geospatial example because it's placed out of this repository. We should update Geospatial example.

https://www.w3.org/TR/webxr/#xrwebgllayer-interface

The buffers attached to an opaque framebuffer MUST be cleared to the values in the table below when first created, or prior to the processing of each XR animation frame. This is identical to the behavior of the WebGL context’s default framebuffer.

For example, WebXR samples AR hit test example expects it so doesn't clear in their side.

We want to embed dist/webxr.js and xrshim.js to webxr-ios so maybe we should move (or copy) them under webxr-ios/XRViewer/Resources

In Anchor API spec, addAnchor() has been moved from XRSession to XRFrame immersive-web/anchors#27 We should update to follow it.

Hello, I created a webXR dance experience that is working fine on Android.

When I load in webXR Viewer it just displays a black screen.

You can try it at https://pararty.com/

1. What's a good way to debug this?

2. Is there a way to detect webxr-viewer browser with JS?

Thanks.

Even a simple inline device, akin to the trivial one in the polyfill, would be sufficient (e.g., it doesn't use device motion).

WebXR Anchor API seems to be finalized soon. We should update our Anchor API to follow the newest spec once it lands.

https://immersive-web.github.io/anchors/

When you click on a link whose HTML attribute is target="_blank" to open it in a new tab, the application suddenly closes.
For example : https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_a_target

Hi, how are you? I need a big help.

Currently I am developing WebXR solution for public AR services.

So far I am appreciating mozilla WebXR viewer which makes iphone users can enjoy Web AR contents.

However, I found a resolution issue which happens only to iphone users; so I assume that it happens because of WebXR viewer.

The AR content image looks like downgraded.(Resolution Issue)

I also tried other simple 3D objects for AR and it works well.

I wondering whether it is because of the image map issue(size, etc.) or it is because of heavy 3D model issue(size, mesh numbers, etc.)

Please let me know if you have any solutions for it.

I attached 3 images; first one is an original 3D model image(glb), second one is an iphone issue screenshot, and third one is a screenshot of the same model loaded in android phone.

Thanks for your help.

As of January 1 2019, Mozilla requires that all GitHub projects include this CODE_OF_CONDUCT.md file in the project root. The file has two parts:

1. Required Text - All text under the headings Community Participation Guidelines and How to Report, are required, and should not be altered.
2. Optional Text - The Project Specific Etiquette heading provides a space to speak more specifically about ways people can work effectively and inclusively together. Some examples of those can be found on the Firefox Debugger project, and Common Voice. (The optional part is commented out in the raw template file, and will not be visible until you modify and uncomment that part.)

If you have any questions about this file, or Code of Conduct policies and procedures, please see Mozilla-GitHub-Standards or email [email protected].

(Message COC001)

From #34

shim asynchronously loads the entire webxr-polyfill.js on demand when navigator.xr.requestSession() is invoked

navigator.xr.isSessionSupported('immersive-ar').then(supported => {
  if (supported) {
    navigator.xr.requestSession('immersive-ar').then(session => { // the entire polyfill file is loaded
      ...
    });
  }
});

So there are some limitations compared to the native WebXR API support. A limitation I'm aware of is XR* aren't defined until the entire webxr-polyfill.js is loaded. For example the following user code judges that the browser with shim doesn't support WebXR API.

const supportsWebXR = (window.XR !== undefined);
if (supportsWebXR) {
  // browser supports WebXR API so going forward
  navigator.xr.isSessionSupported(...).then(supported => {
    if (supported) {
      navigator.xr.requestSession(...).then(session => {
        ...
      });
    }
  });
} else {
  // browser doesn't support WebXR API so stopping with error message
  console.error('Your browser doesn\'t seem to support WebXR');
}

There may be other limitations.

Perhaps shim works fine for most of general use cases so accepting such limitations may be an easy solution.

WebXR changed the global name to XRSystem. Needs updating here

From #33

Currently we support old hit test API. We should support the newest one.

And the old explainer seems being out dated soon.

i'll leave this for you @blairmacintyre

frame.getPose is synchronous and can only be called when frame is active, but addAnchor returns a promise with getPose inside it.

Solution would be to somehow not need to call getReferenceSpace inside. I think "local" is always identity (?) so perhaps we can just get around it by not getting the space AND not even calling getPose?

We already support requestHitTestSource/Results but doesn't implemet requestHitTestSource/ResultsForTransientInput yet. We should support them, too.

Google`s <mode-viewer> uses them. Unless we support them, it doesn't work on our platform.

From #60.

We updated shim to expose XR* classes to resolve the limitation pointed out in #58. But it still has another limitation.

• XRRigidTransform should be able to be instanciated by user even before starting session but the current shim prohibits

Perhaps we can work around this limitation with the idea mentioned here tho the code could be a bit mess.

Hello,
It seems, that new features and experimental features of WebXR are not supportet.
Could you please update the app with the newest webXR API version?

Thank you!

From #60.

We updated shim to expose XR* classes to resolve the limitation pointed out in #58. But it still has another limitation.

• EventListeners/Events for navigator.xr should be able to be added/removed/dispatched by user even before starting session but the current shim prohibits

Perhaps we can work around this limitation with the idea mentioned here tho the code could be a bit mess.

Forward direction should be [0,0,-1], not [0,0,1], so it's failing on some apps.

is the custom override XRFrame.prototype.getPose() in our webxr.js still needed? The comment says it is there because of some bugs in the real one. But the referenced issue looks to be resolved?

hey @blairmacintyre where are the existing images stored? In a different repo?

From #60 (comment)

Extending XR* classes by user before starting session is problematic on the current shim.

1. Adding methods like we webxr-ios-js do

XRSession.prototype.extra_method = function () {
  ...
};

2. Extending class (not sure if extending XR* makes sense but it should be able to do)

class CustomXRSession extends XRSession {
  ...
}

They extend old fake XR* classes as probably user unexpects.

1. can be tracked and we can reflect to new XR* like this maybe? But perhaps no solution for 2.?

Another question is, should we really take care about these hacky and rare use cases?

https://www.xrdinosaurs.com/

XR Dinosaurs example made by Toji in AR mode should render a dinosaur on Camera. But our viewer doesn't show camera. I guess it doesn't clear a scene background?

It might be possible to leverage the InlineDevice from the real polyfill, if we can revert to using the original requestSession and somehonw "install" our ARDevice

I don't think I should be setting imageActivateDetection = false; inside the activation promise return; it should be true as long as the image is created, I think

All Three.js examples are displaying "WEBXR NOT AVAILABLE":

https://threejs.org/examples/?q=webxr

I am using iPadOS Version 16.3.1. Is this a known issue?

Would it be possible to implement a custom url scheme, like wxrv:// which was present in the first version.

It doesn't seem our WebXR polyfill supports WebXR input event. Instead the examples in splash.html uses external example/XRInputManager.js to handle input events without WebXR input API.

We should support WebXR input event properly in our WebXR polyfill and rewrite our examples to the ones with proper WebXR input API. Otherwise user WebXR applications using WebXR input events won't work, for example Three.js WebXR AR examples or WebXR samples AR examples.

Eventually, I think we will need to instantiate class dummy objects for every class before loading the polyfill, so people can monkey-patch them. I think doing something with internal private methods may make this easy, so that we “implement” all the method of each class, but have them call internal private version, initially null. When we load the full polyfill, we just patch the internal methods. That way, if someone replaces “init()” in this code below, with a new method that calls the original init(), it will still work.

Class foo {
       privateMethodFooInit = null;
 
       init() { if (privateMethodFooInit) { privateMethodFooInit()} }
}

Off the top of my head, that’s it.

From #28

We have our own webxr-polyfill.js fork because the official webxr-polyfill.js has some issues for us

• requestSession() doesn't take the second argument yet (immersive-web/webxr-polyfill#95)
• It includes huge Cardboard module which we don't need (immersive-web/webxr-polyfill#56)
• It doesn't fully support getPose() yet (immersive-web/webxr-polyfill#92)

We should track the issues, work with them, and switch to the official webxr-polyfill.js from our own when the problems are resolved.

BTW right now our own fork is placed at my personal repository. I think it'd be safer if we move it to the Mozilla repository so far.

I think we should clean up the code. Currently the code looks a bit dirty and readers may think it isn't ready yet. For example it has

• Inconsistent coding style
• Inconsistent indentation, hard tabs or soft tabs. And some of the indentations are broken
• Out date comment
• Lack of comments
• etc.

Installed the app on iPhone 11 Pro. Tracking seems to be motion, but there is no camera feed during the experience. Have tried with multiple experiences. iOS Version is 13.7.

WebXR samples Barebones AR example doesn't work. (DOM-overlay is optional so it should work even without DOM-overlay support. And the root issue is not related to DOM-overlay as I explain below.)

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

Error log on console is

Error: Shim: We don't expect user adds event before starting session.

As the message describes, the example sets event listener navigator.xr.addEventListener('devicechange', event => { ... }) before starting session.

https://www.w3.org/TR/webxr/#xr-interface

This usage looks valid so hopefully we should resolve this problem in our side.

Related: #77

Google's <model-viewer> AR example doesn't recognize our API our WebXR Hit test API even with #82.

They seems to check Hit Test API availability with window.XRSession.prototype.requestHitTestSource !== undefined before calling navigator.xr.isSessionSupported().

But our shim only defines the classes and doesn't define their methods. So .requestHitTestSource will be undefined then they determines that our browser doesn't support AR hit test API.

Maybe related #77