2023 Servo
- Date: 7th Jun 2023
- Issue: https://github.com/Igalia/webengineshackfest/issues/16
Emilio: ideally we can have something similar to how we sync WPT, with the caveat that we can’t drop anything like we do with tests
Oriol: we used an approach like we do for WPT, but if you import something and a test fails, you can just mark that as failing. Stylo changes would probably require more manual work in some cases. Emilio was saying maybe we shouldn’t force Firefox developers to fix breakages.
Emilio: if we have an automated build that imports changes from Gecko into Servo and builds and tests it, that will save a lot of the boring work, even though it’s not fully automated.
Martin: those kinds of solutions where we partially automate something and make a comment on Bugzilla or GitHub are a great approach. There are also ways we can reduce the need to make changes in style, like prefs [? missed this]
Emilio: prefs live in a yaml file somewhere, with another layer of build scripts. Just making sure that the Servo and Gecko prefs macros use the same syntax would help.
Martin: in general, if we can reduce the amount of #![cfg] macros and conditional compilation, it seems like there would be less breakage.
Andreu: I’m interested in larger changes, for example, SpiderMonkey removing readable streams last year. How can Servo and Gecko make sure these large-scale divergences don’t happen?
Emilio: without being too involved, I think the readable streams issue was an uncommon case where SM implemented something then realised this is not the best way of complying with the spec. But in Stylo at least, we’re happy to make changes to accommodate Servo.
Martin: WebRender was originally only used for Servo, and Servo relied on a lot of functionality in it, for example, the concept of scrolling frames. This was removed from WebRender because the upstream[?] is really only used by Gecko. It’s probably better if we’re more conservative about what we rely on from upstreams we don’t control, so for example, our own hit testing.
Emilio: the thing Servo relied on wasn’t particularly good, and it’s a burden to keep both right? It’s a bit tricky to maintain something like readable streams when they aren’t used upstream, because the code isn’t getting built. For style, we’re happy to coordinate with Servo, and it should be the same for WebRender if they need to make major changes. Part of the issue is that for a long time, there was no active maintainer on the Servo side.
Martin: what is the general philosophy of Servo’s relationship to Gecko, since we rely on some important libraries in Gecko? Can we make our usage of those libraries more consistent and predictable? For example, this will be the first WebRender upgrade in three years. If the Gecko team knew that we were going to update every six months, would that be easier?
Emilio: Maybe. For style, most of the breakage is minor. Also, what's the influx of changes? Spidermonkey doesn't live in the Servo repo but style does.
Martin: would it be reasonable to release the style crate to crates.io?
Emilio: it’s reasonable, but every time you implement a new property in Servo, you’re going to need to change the style crate. It seems kinda silly to make a patch to mozilla-central, prepare the crates.io release. For WebRender maybe, for style it would be too much of a burden for the Servo folks.
Oriol: Why doesn't Gecko lint/format? I sometimes have to ignore files
Emilio: Servo was using Rust nightly with an unstable configuration. That's why rustfmt doesn't run by default in servo, there's different formatting from mozilla-central. Webrender runs servo-tidy and this needs to happen in gecko CI. Prefered solution is to merge patch for rustfmt that ?. Can we make Servo run rustfmt?
Martin: Gecko uses stable rust?
Emilio: Not the latest stable. We update frequently. We can tweak the version of rustfmt we run.
Martin: We can discuss the version we rust. We use nightly features, but we don't need bleeding edge nightly.
Emilio: A lot of the style integration is low-hanging fruit, formatting and syntax related things. We should create issues for these.
Rakhi: How do we imagine the future of style in Gecko?
Emilio: I don't care as long as we don't duplicate work. Let's make sure we have a path of not maintaining it separately. A lot of Servo components like selectors will probably get new features from Servo and that’s totally fine. If only Servo needs it, we can add a runtime or compile time switches, but we need a path forward for integrating Servo changes upstream as well. I don’t think treating Gecko as The Upstream where everything needs to happen, and requiring people to send patches to mozilla-central, is very reasonable. Better to allow contributions on both sides and have a way to sync them.
Martin: We're a ways away from being in sync, but it'd be good to integrate it similar to WPT.
Emilio: A lot of WPT integration can be reused. It might be reasonable to sync to Gecko in the same way it syncs with WPT.
Martin: We'd have to figure out what is the upstream.
Martin: servo has an embedding API in rust, but there’s also a C API. But embedding servo has some unique challenges. One is that servo takes a long time to compile, which would be huge for people using e.g. Tauri where you expect compile times of a few minutes or seconds.
Martin: there’s no rust ABI, so you can’t ship a shared object with a rust interface, it would have to be a C interface.
Emilio: we can also ask embedders to use a specific rust compiler version, which would yield an effectively stable ABI.
Andreu: I saw Rust was working on a cross-language stable ABI, crabi. But it's a long time away.
Emilio: I don’t think we can expect a stable ABI for rust to happen any time soon.
Jonas: Tauri has no precompiled binaries, you compile everything from scratch.
Martin: another approach, servo has a C API, so we could bless that API and then build a rust wrapper around that C API, so rust → C → rust. We could use something like Tauri’s generic web view API.
[? missed the last point -- something about Diplomat?]
Martin: would it make sense for servo to implement a generic API, so that embedders can start with another engine, then as servo becomes more mature, they can flip a switch to try servo?
Jonas: that would be super cool, but it has challenges. We have a trait, but it’s rather annoying to deal with if you want to make larger changes.
Emilio: we should first figure out our API more thoroughly, then we can build that as a C API and a rust wrapper on top, like Martin mentioned.
[?]: Who is interested in embedding Servo?
Martin: there are a handful of projects like Tauri, but there are also possibilities for products that need a little embedded webview, and those seem like an obvious application for servo.
Jonas: the big struggle with webviews right now is that you basically have two functions you can use to control them. Servo has the potential to offer a webview that allows for more control, and more extension points.
Rakhi: Another point would be to have a a Servo binary download that users can download and test on. such as to run demos and to test other things on servo.
Delan: For similar reasons, having embedded devtools would be reasonable, to help embedders figure out what is supported.
Emilio: if you have not great internet, it can be hard to build servo, and this is true for all browser engines to varying extents. This is especially true for cargo, though it doesn’t really affect Gecko because we vendor all of our dependencies there.
Martin: servo has a huge dependency graph, perhaps reducing the size of that would make it easier to build servo.
Jonas: the bespoke tooling adds a layer of complexity as well.
Martin: is it jarring for rust developers to have to use mach instead of cargo?
Emilio: a lot of the reasons for mach came from a time where you had to pull in a lot of external dependencies, like a C++ toolchain. These are things that would be even more painful to do in a build.rs or similar. At some point, cargo build worked, then we made mach work but change some configuration. Can we avoid that?
Martin: We could make cargo call mach. Not great, but it would be less jarring for Rust devs. What do other Rust projects do when they need system dependencies? We could say "run mach bootstrap, then run cargo".
Emilio: For people contributing to a Rust project, usually cargo build, cargo run just works. Reading the readme would be nice. But making cargo work would be useful.
Martin: Running cargo build might not work. But we can fix that. But when Servo started, cargo didn't exist, and then it didn't have all the features it has now.
Emilio: yeah, for example, there wasn’t a way to guarantee that you were using the right version of the rust compiler, but now I think cargo supports that with the rust-toolchain option?
Jonas: It seems like cargo would be happy to make changes to accomodate servo.
Martin: Servo has had an organic development style, and there's no overall design philosophy for the code. Can we make changes so the code is easier to understand?
Emilio: Servo usually had a design goal. Layout 2013 wasn't though. But some of the DOM bindings are kinda magic and it's not clear what they do. When you know how the bindings generate C++ classes, with codegen.py etc, I always found that a bit weird.
Martin: Do you think the bindings could generate Rust structs?
Emilio: No... I don't know if there's a solution for that. script takes a long time to build...
Martin: Do we know why it takes so long?
Emilio: The bindings generate a gazillion traits.
Martin: How reliable is incremental compilation in Rust?
Emilio: I'm not sure if sccache makes things faster. It does in Gecko.
Martin: It does.
Delan: I thought incremental compilation was disabled in a version of Rust. Has that been fixed?
Jonas: I think it was reenabled pretty quickly. It was a high severity issue.
Emilio: In Servo it seems incremental compilation is disabled in the mach build config.
Martin: The script crate is a problem for dev experience, because when you touch the DOM bindings you have to recompile all of it, and it takes a long time. There's been efforts to improve this, and we could try enabling incremental compilation again, or we could try splitting the script crate (https://github.com/servo/servo/issues/1799). But there are two-way bindings... Or we could look into making compilation faster in general, but might not be easy because there's a lot of SM binding code.
Martin: are there ways we can better communicate what we’re working on in servo?
Rego: Maybe we could make Youtube videos like Andreas Kling, from Serenity OS / Ladybird Browser.
Andreu: That's not a bad point. We have some presence in social media, but we maybe should have something more engaging for contributors.
Rakhi: target more conferences with beginner kind of talks and even conference where not a lot of people with prior rust & servo experience.
Andreu: For the Rust community, a lot of people know about Servo, but they might not know work on it has restarted. I think more outreach is needed.
Jonas: Make contributing to Servo seem cool, similar to Rust project.
cybai: Find spec updates that need to be fixed in Servo and create issues. This can help fix the WPT test failures.
Martin: Good point. Once we are done with inital layout work, we will be a good position for accepting contributions.