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.
I'm really proud of what the Servo team has achieved and since I'm always looking at it from a big distance, I believe you are all able to judge this much better than me.
That said, this news do not sound good to me. Again, this is from a great distance, but from here, taking a future-focused team with great respect from the community, a team with an important and invaluable mission and that has successfully delivered over years, and shifting it (or forking it) towards complete uncertainty feels like a dangerous move that reminds me of the phone OS efforts.
Good riddance and may your vision be right. We need someone with Mozilla's goals looking deeper into VR so that we don't end up in the hands of the Big Corps in the near future, that is for sure, no matter if VR ends up being niche. How important that technology will be for the masses is yet to be proven and that's why I fear for the web, the battle proven real thing that faces the greatest threats from closed silos today. I don't feel it should be taken on equal terms with what is still fictional speculation. It needs full energy to make it to the future in good health. We already failed to deliver a beautiful, open and user centered internet to the future, we can't loose the open web.
>> 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.
So building a fully functional browser is not higher priority than getting the half-baked browser working in a niche environment? I'm half joking here, and half serious. How is a browser supposed to look differently in VR? And why does it need to be aware of the fact that it's in VR? People are still developing interaction and navigation methods in VR.
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.
So is this the end of the attempt to make Servo into a fully web compatible competitor to go up against/replace Gecko, et al? Was that ever the goal, really? It seemed like Servo was a "let's see if we can do it" and now it's changed into a "what's the point of putting all this effort into making one more 2D web renderer when we can be at the forefront of 3D web renderers?"
Not passing judgement on anything with the above statement. Just trying to make sense of it all.
We're still working on web compatibility; that's not changing.
But I don't think we've ever had a concrete goal to have a standalone Servo browser. Parts of servo in firefox? Sure. Trying out new ideas? Sure. Embedding servo a la electron or WebkitView? Sure. But Servo as a standalone browser has always been a "maybe someday" thing -- we've never worked against it, but I don't recall us ever explicitly targeting it, though I think most of us have always had some hope that we'll reach that point eventually.
What about the concept of turning Gecko into Servo piece by piece?
That is, continuing the Quantum work until there is either no C++ code left, or the C++ code left can turned off via config option ("prefer perfect security over perfect compatibility") while still having a browser that works on the vast majority of the web.
Servo components will continue to be uplifted into Gecko (e.g. WebRender and Pathfinder are on track to be in Firefox later this year). But ever since Servo's original announcement people from Mozilla have been explicitly saying that people should not expect Servo to wholesale replace Gecko in Firefox.
I wish everyone on the Servo project the best of luck, and hope this new project will be a success, but I can't help but agree with other commenters who see this as a move away from something that could have provided a huge fundamental advantage to Firefox/Mozilla to something less impactful. This feels like the end of the Servo project in all but name.
I have my doubts as well, but one way to look at this announcement in a charitable light is that VR and AR are technically demanding use cases which will require the Servo team to keep a strong focus on performance. In one way, it's a good testing ground for further refining the high level of performance that Servo has already achieved, especially if the work aims to make the user experience of shifting between 2D and 3D content to be seamless (which could result in performance wins for 2D content as well).
I still have a hope that Servo will be used in a next-generation Electron competitor, as that's what I thought would be the best use of Servo (in the short term). Hopefully the developers can keep this use case open by maintaining the code that allows Servo to be embedded as a component in other projects.
To me, the promise of Servo was that we could incrementally rewrite Firefox in Rust, evolving Rust alongside it, and solve memory corruption in a browser, making a giant leap forward for security. Servo was the credible alternative to Chrome's approach of just adding more sandboxing. I'm just disappointed.
> 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.
This is extremely disappointing.
I think the amount of users you can win back from Chrome with a Servo browser is much larger than any VR audience you can hope to gain in the near future. I simply don't understand how these things cannot be done in parallel. Mozilla has hundreds of millions in cashflow, right?
Looks like Servo will be another exciting Mozilla project that will be prematurely dropped after a ton of work and hype-up. RIP Firefox OS, Persona, Thunderbird, etc... :(
> I think the amount of users you can win back from Chrome with a Servo browser is much larger than any VR audience you can hope to gain in the near future.
A Servo browser product is not possible in the near future. That is very much a far future thing. Web compatibility is hard.
Servo has a lot more potential in platforms where you don't need to support the _entire_ set of browser features -- like as an electron replacement, or a platform for something like webVR, or Android embedding (which will probably come out of the VR work as well).
> A Servo browser product is not possible in the near future. That is very much a far future thing.
and an impossibly far future if the Servo team is now refocused on VR, no? how likely is it that these hard problems will be solved by fewer engineer-hours?
perhaps there's some external backer willing to bankroll VR and Servo is just an easy expense to curtail.
Focusing on VR means that we may not be working on some kinds of webcompat things (the standard example is "IE6 table layout quirks") but there's plenty of webcompat work that needs to be done otherwise.
Yes, not everyone will be working on webcompat, but this has never been the case anyway.
> (the standard example is "IE6 table layout quirks")
if a new browser in 2019 could not properly render an archived 1996 Geocities webpage at time of launch, i don't think many users would care or even notice. there are almost certainly legacy bugs in Firefox that have been open for over a decade with little activity and yet it's in production.
Having folks spending months implementing the corner cases of standard might not researching and finding creative ways to use Rust to implement large systems.
Standards compliance probably follows some exponential curve wrt energy and results.
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.
Linux (and macOS) should work on Firefox Nightly. For both, the Valve services are currently in beta and we can't really ship something that relies on beta drivers past our own beta releases.
If you encounter any bugs on Linux or macOS in Nightly, please do report them! The team is awesome about testing and fixing them. That said, the VR & driver/OS stack for support on those two platforms is still seeing a lot of flux and is not yet at the same level of performance and stability as Windows, depending on which particular version you grab.
It spams "[GFX1]: SharedSurfaceType::Basic not supported for WebVR" to the console and doesn't send any frames to the SteamVR compositor.
And as I understand it, the OSVR implementation never even bothered to implement OSVR-Rendermanager support, let alone fix the tab crashing after 1-2 seconds.
I'm pretty sure they all know it's broken. A while ago kip said he wanted to work on OSVR "soon" and later that we could expect WebVR on Linux "soon", but it looks like he is literally the only one who wants to work on it and doesn't have the time, at all. After all it's still an open bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1310663
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.
Perhaps what I said was ambiguous. The error message is from the OpenVR support.
The OSVR support wouldn't have such an error message because the rendering support wasn't implemented in the first place.
I understand the reluctance to spend time investing in it, especially when developers say the OSVR-Rendermanager API and the OpenGL context sharing is awkward to use, but what's the point in investing in it in the first place, with a big announcement from Sensics http://sensics.com/osvr-comes-webvr/ etc?
The thing is, at the moment the only OpenVR implementation is the proprietary SteamVR runtime and it looks like it's unlikely that anyone will implement a FLOSS OpenVR runtime. Isn't Mozilla usually all over libre stuff like OSVR?
Not even ideologically, imagine you're buying a Talos II POWER9 Workstation, plop a Vega 64 in, compile firefox, connect your HMD, and what's that? SteamVR is only available on x86? Tough luck, no WebVR for you! Meanwhile you can compile OSVR for whatever architecture you like.
> though certainly if more devices that can only work on OSVR
There's no such thing because with SteamVR-OSVR all OSVR supported devices can be used in SteamVR (they are having some trouble with controllers, e.g. the Nolo controllers, but that's getting sorted out currently).
The point is really more that Mozilla seems to give a lot more love to proprietary platforms like windows and runtimes like steamvr now than to libre ones.
It's funny because in 2014/2015 with the Oculus Rift DK2 we first got a chromium webvr build for linux and then when it got into firefox nightly, it worked on linux too. Then Oculus stopped their linux support and both browsers stopped caring about WebVR on linux too. That announcement from Sensics is a year old and falls in the time where the OSVR SDK was the only major current and working VR SDK on Linux (and Mac OS X!) but it seems nobody wanted to make the effort to actually make it work. Fair enough, the OSVR SDK is an SDK literally nobody on Linux uses, so we could wait for SteamVR. That came out in February and today here we are, wondering what the problem is.
Artists are doing amazing things on the Sketchfab platform and (as a browser implementer) I'm continually impressed by how hard their team is working to make their viewers work well in all the browsers! It's particularly hard with the spec only just now becoming compatible and getting tests working across them. There are still a lot of quirks to sort out (link navigation, rAF interactions, implementation-specific performance issues, etc.). They're doing great work!
I'm not quite ready to throw in the towel yet, though that's certainly a sentiment I hear a lot of around town :-)
As technology shifts to a world where most people do not have a monitor on their home computer or a screen on their phone, what it means to be a browser will dramatically change. Certainly, we could post-it the current user experience into whatever we will have tomorrow, but if VR, AR, Speech, and AI and ample cheap private computing power don't excite people for the future of browsers and user agency, I don't know what will.
I know we've been working on tech such as Servo for a long time, but sometimes even just being "better" isn't enough, especially when there's a large legacy gap to close. You also need to get lucky with a point where consumers are making massive changes and open to new things.
I think that time is much sooner than the "always 5--10 years quoted", and you're going to see mind-blowing things on the web in general and supported by the browser and related services specifically. And I'm betting (at least with my current career) that Mozilla will lead the charge.
TBH, it's been hard to prioritize work to fix OpenSSL issues when we all knew it was going away from the dependency list. However, I don't think anybody anticipated the scope of work required to get there :-)
I understand, but then why bundle it for MacOS & Windows, and not Linux ? Couldn't they, too, wait for OpenSSL to go away ?
Note that I fully support using a clean rust-based TLS implementation. Given how young servo is, it will have time to mature before Servo becomes widely-deployed. I just think this is an orthogonal problem.
PS: thanks for taking the time to answer here and keep up the good work !
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.