The Navigator Identity Crisis: A Call for Design Sovereignty and Customization.
To the Meta Design Team, you are making your device worse by trying to be someone else. Meta was the leader because you were the ones who actually figured out how to make standalone VR functional and accessible in the first place. For you to throw away the very leadership you built just to become a knock-off version of Apple is a total failure of vision. You didn’t need to reinvent the wheel, you just needed to polish it. Instead, you’ve scrapped a great, functional interface for a filtered version of the Vision Pro. By forcing the Navigator into a rigid, head-locked position, you’ve sacrificed user sovereignty for a spatial look that you don't even have the eye-tracking hardware to support on your current mainstream headsets. Even if your next device has that hardware, the millions of people using your hardware right now shouldn't be forced into a "look-to-lock" logic that makes the system feel broken. Taking away the ability to freely grab and park windows, forcing us to re-center our entire world just to move a menu is a massive UI/UX regression that makes the system feel less capable and more restrictive. This interface feels like it was designed by geeks who prioritize clean code and data structures over how a human being actually moves their hands and head in a room. Mark Zuckerberg started with a site that was nothing but white backgrounds and blue text a bland, sterile database and that same nerd logic has now infected the Quest. A nerd designs a menu based on where it’s easy for the code to sit; a designer or a real user needs it where their hand naturally wants to reach. Your current interface is the definition of mayonnaise tech: bland, sterile, and corporate. You finally made the Navigator transparent, but you stopped halfway. Transparency isn't just a style choice; it’s a mechanical need in a spatial environment. Why are the store, the menus, and the sub-folders still stuck in these solid gray and white blocks? Every single window should be transparent by default. This is the obvious direction for the medium, yet you're forcing us into light versus dark folders instead of just providing opacity sliders. Users need the ability to choose if they want to block the world out or let their room shine through. It is 2026, so being stuck with gray and white as our only options is a joke. A simple color wheel for the UI would allow for a green aura, a blue glow, or custom highlights for menus. A transparent green theme should be a simple slider adjustment, not a corporate mandate. You already had a winning format with the original Quest interface. You didn't need to scrap it; you just needed to make it transparent and give us the tools to move it. You need to restore the "grab-to-slide" logic so we can orbit windows 360 degrees and park them to our left or right without the system fighting us. Stop trying to look fashionable through imitation. You built your success on utility and being the original in the standalone space, don't throw that away to be a second rate copy of a competitor. Give us back the original soul of the Quest, enhanced with the transparency and the customization that this technology actually demands.Shared Mode, Browser app access?
I have a need to allow my Shared Mode headsets access to the Browser app. Support told me this was currently not an option. Please allow this app to be added to the managed apps page on the work.meta.com site > Apps & content page. It should be up to me (the admin) whether that app is secure or not for my use. I'd also really like it if I can set the starting page of the Browser app to a specific URL in this scenario. My use case for this is... We're a construction MEP engineering firm where we're primarily using the headsets with the Autodesk Workshop XR app, BUT we have a need to also access Matterport's website to view 3D scans in VR. I would however prefer to setup our headsets in Shared Mode so that many different users can simply hop on a shared headset and more easily get right into these specific workflows.
WebGPU Compute into WebXR on Quest
Anyone know the expected date for Meta Quest's WebGPU-WebXR layer? i just purchased a MetaQuest 3, to complement my Quest 2, for WebXR development *with* WebGPU ( Compute-Shader only Voxel/SDF engine ) and found Meta-Browser's doesn't support WebGPU-WebXR, a 'Chromium 134' stable feature. Suprising since Quest 3 is a "Flagship of XR" device ( in terms of sales/popularity/development ). Reference check here: https://immersive-web.github.io/webxr-samples/webgpu/ i've web-searched extensively yet not found a workaround/flag to set or anything to do other than the suggestion to build a WebGPU copy into WebGL context ( wasting bandwidth/VRAM on copying the XR canvas? ) Am i missing anything? Thx---
Request: WebXR Raw Camera Access (camera-access feature) in Quest Browser
Hi Meta team, I'm building a WebXR mixed reality application on Quest 3 that uses computer vision to annotate real-world objects in AR — think floating info panels anchored to products on a store shelf, triggered by voice commands. The app uses Three.js + React-three/xr and connects to backend AI services for object detection and enrichment. The missing piece is camera-access. When I request it: ``` navigator.xr.requestSession('immersive-ar', { requiredFeatures: ['camera-access'] }); ``` The session is rejected with: `Feature 'camera-access' is not supported for mode: immersive-ar` This is on Quest 3 running Horizon OS v85, Quest Browser latest. Why this matters for WebXR: The Passthrough Camera API is already available on native platforms (Unity, Unreal, Android) since v76. Bringing it to WebXR would unlock a category of browser-based MR apps that currently require a full native build pipeline — real-time object detection, visual search, accessibility overlays, educational AR, and more. WebXR's strength is zero-install, share-a-link distribution. Pairing that with camera access would make Quest 3 a much more compelling platform for MR web apps. Current workaround: I'm using getUserMedia as a fallback to capture camera frames, which works but loses the per-eye reprojected textures, pose-aligned intrinsics, and the tighter integration that the Raw Camera Access spec provides. The app is architected to switch to camera-access the moment it's available— no code changes needed on my side. My request: Is there a timeline for camera-access support in the Quest Browser? The https://immersive-web.github.io/raw-camera-access/ is defined, Chrome has supported it since r107, and the native Passthrough Camera API is already shipping. Would love to know if this is on the roadmap. Thanks for all the work on WebXR support — hit-test, hand tracking, plane detection, and anchors have been great to work with.Accessibility Feature Request: Conversation Focus Mode for Ray-Ban Meta Display Glasses
Hi everyone! I’m a Ray-Ban Meta display glasses user who is hard of hearing and wears hearing aids daily. I’d love to see a conversation focus mode added that prioritizes voices directly in front of the wearer and reduces background noise. In busy environments, this would make a big difference for hearing-aid users and others who rely on clearer speech in real time. If this type of accessibility feature is ever developed, I would absolutely love the ability to have it added to my glasses and would be happy to provide feedback or participate in any beta or user-testing opportunities. I’ve also submitted this through support channels, but wanted to share here in case the team is gathering feedback.Building NE9: A Runtime and App for AI-Driven Interactive 3D and XR Worlds
Hey everyone, I wanted to share what I’m currently building and open it up for discussion. I’m developing NE9, also known as NastyEngine 9. It’s a modular, real-time runtime designed to integrate AI systems, 3D environments, and interactive applications into a single live pipeline. Alongside NE9, I’m building a companion app that interfaces directly with the runtime. The goal is to use it as a control and integration layer where scene logic, agents, and interaction can be composed and updated live instead of being locked into a traditional editor workflow. The core idea is to treat AI, rendering, networking, and interaction as runtime-orchestrated systems rather than isolated tools. This approach makes it easier to experiment, iterate, and eventually extend into XR and VR environments. This is an active build and the architecture is evolving quickly. I’ll be sharing progress, experiments, and lessons learned as things continue to come together. This screenshot shows where we are right now in the development process. This was our first full session using Meta Quest 3 connected to our desktop via USB, running the Meta desktop app as our development workspace. We were viewing and working directly with our existing tools inside the headset to get a real sense of scale, comfort, and workflow. It was our first serious hands-on development session this way, and getting our feet wet was a lot of fun. Even just working from the desktop inside the headset made it clear that this is a platform we’re excited to build for. We’re looking forward to transitioning from desktop-based development into deeper Horizon and native XR workflows as NE9 continues to evolve. If you’d like to connect, feel free to check out my LinkedIn. Thanks for stopping by, and I’m excited to see what we can build together. https://www.linkedin.com/in/daniel-harris-0745b8374/
webXR on Meta Quest scan QR code?
Meta Quest with webXR and passthrough I have a webXR project with passthrough and this is working perfect on the Meta Quest 3s with the meta browser! Scan a QR code? But now I want to scan a QR code (printed on paper, laying on the table in the real world) in order to place digital content on top of this QR code. My browser is on the latest version 40.2. I was reading that webXR did not yet have access to the camera API. Is there some progress on this? When can we have access to the camera? Other solution for QR scanning? Or is there an other solution? I do not need the full camera access but only detect the QR code? We made QR scanning with meta quest working in Unity while access to the camera API is available in Unity. But as said we are really looking in this simple QR scanning solution for webXR? As addition to this. We work with three.js. I really hope that QR scanning will be available. This could make AR tours with QR scanning much more easy. And this scanning of a QR should only be done for example 2 times a second. Just to place the content on top of a QR in near-real-time. I really hope to hear
