larsberg

scudo has been the default allocator for Android since Android 11, and we are hoping to make it mandatory for the few remaining places that don't use it. Using an allocator without memory protections in 2026 (especially after we have closed nearly all known performance gaps with jemalloc) is really not a great choice.

Actually, it's complicated stuff pulling together two data points: 1) 2/3 of people are confident contributing in 2 months or less 2) And 50% of people are AS PRODUCTIVE IN RUST as they were in their other language within four months

Given that #2 is talking about people who are all professional programmers and where only a small percentage of respondents previously knew Rust, that's pretty amazing to me.

Gah! Typo there. It's over 50% (66.8%) in 2 months. And over 80% in 4 months. The chart is correct, not the text :facepalm:

I'll see about whether I can push an update. Thanks for the catch!

Thanks for all of your work (in addition to that of others) - it really shows! We do encourage people to create minimal repro cases and open bugs whenever possible. And, even more ideally, to consider contributing a PR upstream...

That's exactly right. Today, the focus is on making it possible to use Rust to write pieces of the Android platform itself.

Certainly, there are some _apps_ on Android today that use Rust (shout-out to my Firefox friends!), but that's not something I'm investing in right now.

If you haven't seen, I'd highly recommend checking out what we did for IEEE VR: https://blairmacintyre.me/2020/04/02/completely-online-ieee-...

and in particular some of the notes on poster sessions: https://blairmacintyre.me/2020/04/10/doing-a-poster-session-...

In practice, people consumed the keynote/talk content in a variety of formats (streamed, recorded, and in-VR) and there was a fantastic networking and meeting-new-people effect in the poster, hallway (post-talk), and demo sessions. There's a bunch of formal research that was done there along with post-conference surveys to track down specific data (e.g., how many new people did you meet?) but it will take some time for those teams to rigorously collect & report.

Hi! As we mentioned in the recent Quest release blog post, https://blog.mozvr.com/firefox-reality-for-oculus-quest/, we have some designs for multi-window support and synchronization of content between platforms. We're still working on options around tabs / additional content beyond the number of windows you have open, alongside our really awesome Seattle-based design partners, Podipo: http://podipo.com/

Once we have some concrete designs, we'll have issues open and on our public roadmap for comment and we often have early builds available in our releases page for sideloading if people are interested in testing and giving feedback.

Thanks! We also find that a lot of our users really like watching 360 or even 2D videos, taking advantage of the ability to resize the screen to get their own personal theater.

Right now, we only have Firefox Reality available for standalone VR headsets, but we're bringing the experience to desktop VR and a variety of standalone AR headsets in the second half of this year.

Unfortunately, we don't currently support phone-based Daydream or Gear VR devices. There's both a bunch of extra work to support all of the phone in/out/notification lifecycle scenarios and we have a pretty small engineering team and the long tail of phone/chipset-specific bugs is pretty substantial. We might evaluate support for it or Cardboard in the future, but for right now we're mainly focused on standalone headsets.

That said, we're all in favor of people who want to sideload and play with it! https://github.com/MozillaReality/FirefoxReality/wiki/Sidelo...

Thanks! We don't currently have a build of Firefox Reality available for desktop devices, but that work is currently underway. We announced it as part of our deal with HTC and are excited to show it off soon: https://blog.mozilla.org/blog/2019/01/08/mozilla-announces-d...

If you're interested in this topic, I'd highly recommend watching Stephanie Balzer's sessions at the Oregon Programming Language Summer School on “Session-Typed Concurrent Programming”. The lectures are available online (https://www.cs.uoregon.edu/research/summerschool/summer18/to...).

Her recent work (sponsored, in part, by Mozilla Research) really advances session types and the ability to get termination/progress guarantees: http://www.cs.cmu.edu/~balzers/publications/manifest_deadloc...

This challenge is one of the reasons we're so excited about pcwalton's work on Pathfinder (https://github.com/pcwalton/pathfinder )

Firefox Reality is the brand we're using for the suite of browser products across VR and AR devices.

Today, Firefox Reality is available for standalone VR devices (like the HTC Vive Focus) and is a native Java application that talks to the GeckoView library, which is made up of components from the mobile version of Gecko, the Firefox web engine.

Firefox Reality for desktop will similarly be based off of the Firefox Desktop product pieces.

Note that there's a bunch of "Servo inside" - from small Rust components to the Quantum work including the new CSS style system to the forthcoming WebRender component.

I don't have anything to announce today about a Firefox Reality-branded browser based on top of Servo.

On desktop, it means that if the user chooses to install the Viveport suite, that home experience and the suite will provide Firefox Reality as the default browser.

For all-in-one devices, Firefox Reality will be preinstalled and the default browser.

One of the biggest things we've found that people like to do in VR is private viewing. They'll collect links of videos all day and then come home to watch them on a "big screen" but don't have a laptop or TV that supports miracast, so use a VR headset. Or they like to watch twitch streamers or their favorite movie providers or just bounce around searching content.

As the hardware becomes more mature, we'll support more use cases, but we wanted to enable some compelling early use cases (especially voice search) and learn from users as soon as we could.

While we are on Viveport Mobile and all other relevant stores, a developer can always either build from sources or sideload the browser - https://github.com/MozillaReality/FirefoxReality/wiki/Sidelo...

The issues with text input are a large part of why we added voice input even in our very first release! w.r.t. text rendering, we're doing a lot of fundamental work in rendering higher-quality text (you can't fix resolution fundamentals, but you can take into account the optics of the hardware better than we all do today), but nothing to announce there yet.

Sorry - Firefox Reality is only currently available Viveport Mobile for all in one / standalone devices.

What is up with the duck?

Yes, it's very barebones right now, as the team has been focused on getting performance great inside of standalone headsets. We've found from early adopters of 3DoF and 6DoF standalone VR headsets that media consumption (videos, news, twitch, etc.) is the primary use case and unfortunately pretty choppy and poor today.

We'll absolutely build out the UI and feature set (especially WebVR/WebXR!), but wanted to release as early as possible to transition away from private builds, design, and feedback to public conversations with users, developers, and device manufacturers.

And obviously we're investing in more the ecosystem - we need WebXR fully standardized and supported by all browsers, tools, engines, and frameworks. We also need lots of great content and social experiences that work on the web. We and others are investing a lot in this space - it's going to be an exciting summer!

> How is a browser supposed to look differently in VR?

Great question! Some of the best early work on this was done by ex-Mozilla, current-Google employee Josh Carpenter - check out:

http://www.joshcarpenter.ca/declarative-3d/ http://www.joshcarpenter.ca/vr-browsing-explorations/

There's a lot we can do that is even beyond these early explorations to deliver new features to developers to experiment with and users to try soon via Servo, alongside GeckoView in new VR/AR-focused browser products.

If you take a look at the link I provided above on remaining work and rough estimates to get things just working in Servo (and not FULLY web compat), you're looking at an effort of several years for the entire team, and that's assuming the web platform both stayed still and went ahead and finished writing all the tests and specs for everything on the web that is today neither tested nor fully spec'd. I don't see that in the cards for 2018.

Yes, we're definitely familiar! We have people on the team who have been involved in the area since the first commercial AR systems, and a substantial portion of the team (including myself) lived through the previous era of VRML and VR hype.

Eyes are definitely wide open!

Certainly, it's early stages, which is why we (Mozilla Research / Emerging Technologies) are investing in it.

We're seeing a lot of industrial use of AR in manufacturing and industrial settings, though consumer use is still less common. If you have't come across it, this HBR article is one of the best public materials: https://hbr.org/2017/11/a-managers-guide-to-augmented-realit...

VR is certainly still emerging as a platform and trying to get out of its hardcore gaming and training/corporate silos. We really believe from early user data and some more advanced markets (e.g., China) that standalone VR headsets and great cross-platform social experiences will help it reach more users.

All that said: I don't personally know what the "instagram of VR" will be, though I certainly wish I did :-)

Servo will continue to be a next-generation browser engine and a place where we'll be doing a lot of experimentation on new standards and implementation techniques. I'm sure the community will also continue to use it for all sorts of cool things!

Joining up with the mixed reality team is more about how the Mozilla staff working on Servo will be focusing their time and some of the desire we have for things we want to do for mixed reality that are a little invasive and early-stage of the standards process to be experimenting with inside of existing production browser engines.

With regards to a full browser, there's still a pretty big gap before Servo could stand on its own in a browser (https://github.com/servo/servo/wiki/Remaining-work ). Filling that list out is not a higher priority for the Mozilla staff over getting the stuff done we need to experiment with delivering the web on VR & AR devices.

The awesome folks at Szeged University have been working with our team on both Vulkan and native DX11 backends!

Servo should be referred to as a prototype or experimental rendering engine. If you come across anything still calling it a research project, please let me know! I should have purged them all a year ago, but may have missed some.

Sorry for my ambiguity here! On Linux I specifically mean OpenVR support. We're currently looking more at OpenXR as a cross-device solution rather than investing more on OSVR, though certainly if more devices that can only work on OSVR appear we could resource additional investments.

That particular work is fairly well-separated from the rest of the core of Firefox and doesn't require somebody like Kip or Daosheng with years of experience hacking on VR hardware.