2026 Servo

WEH 2026 - Servo

• GitHub issue: https://github.com/Igalia/webengineshackfest/issues/96
• URL: https://meet.jit.si/WEH2026-servo
• Slides
  • WebNN Experiment in Servo
  • Servo Monthly Updates

Fred + fuzzing

• Fred: Have a set of scripts that run domato and other fuzzers, run lots of instances of servoshell in parallel, then reduce testcases and auto file issues. Questions?
• jdm: Do you run this in the background, or just on demand?
• Fred: Just when I'm busy checking my email or something.
• Martin: Could we run this on a cronjob?
• Fred: Probably, but I'm not volunteering.
• ???: Do you find the same failures a lot?
• Fred: Depends on the fuzzer. Some are more clever; easiest to use DOM APIs so usually find problems in those APIs.
• Martin: from online-based on experience with other browsers, is Servo more robust? Be honest.
• Fred: Started this work doing internal training, tried Firefox and Chrome and found nothing. I don't think people are fuzzing Servo right now, so easy to find problems.
• Jonathan: Would it help to provide Servo builds with Address Sanitizer?
• Fred: Not clear on how ASAN helps, since Rust is supposed to be memory safe.
• Martin: Would be interesting to look at things you've filed and identify common panic sources. Sometimes other libraries, like gstreamer and resvg, or parts of webrender that we use that Gecko does not. Soemthing quantitative could help prioritize.
• Martin: from online-I would love to see panics in non-layout areas like workers, storage, etc. Do you know if domato exercises workers, streams, etc?
• Fred: Maybe coverage-guided fuzzing could help there.

Shubham + WebNN

• Typical AI workflow: Lots of data leaves browsers, goes over network, remote server processes data and performs inference
• There are NPU chips in client devices now, but JS historically can't use it
• WebNN allows access to this dedicated hardware for local AI workflows
• Benefits: removing latency, private, better battery performance than un-accelerated implementation
• Benefits over native: no installation required, cross-platform, refreshing for latest changes, browser abstracts over platform
• Benefits over WASM: dedicated hardware, better battery usage
• Use cases: face/gesture recognition, transcription, image processing, content generation
• Demo! Handwriting recognition in Servo with WebNN
• Created a servo-webnn crate that communicates with backend
• Discovered rustnn crate yesterday
• ??? (author of rustnn crate): There is a servo-ml fork that implemented rustnn using AI tooling which will be discontinued. Would you be interested in porting your rustnn implementation onto the rustnn crate? Goal is to use this crate as the backend for all browsers besides chrome (they have their own implementation).
• Shubham: Want to know how you're optimizing the inference property. Tried to rely on WPT tests, but some models aren't working (??)
• ???: Tests are only as good as people add them. If something doesn't work we should add a test for it! We are starting to add more real world models. We'll work on text-to-speech/speech-to-text models for video conferencing. Missing JS environment where we can run real content. Need to be in browsers to test bigger examples. Help is appreciated!
• Antonio: That was a prototype running in a fork of Servo. Are there plans for merging it?
• Martin: I haven't been following the servo-ml work.
• ???: Presumably shubham's webnn implementation is not implemented with AI like servo-ml. Interest from the project in maintaining that work as the spec evolves?
• Euclid: Demo always used CPU backend. What happens with other ones?
• Shubham: Only tested that backend while trying to get this ready in time.

Delan + monthly updates

• Problem statement: how do we write release notes for a browser engine? how do we continue writing those release notes when the amount of work that lands in this project has increased 5x in the past 3 years (show chart of 2023-2026)
• Misleading data: prior 10 years, from 2015-2018 the project was ~as active as modern era and had This Week in Servo blog posts every week
• The updates used to take ~half a day to write, because it was easier to stay on top of the work happening, smaller window of changes, and only focused on each change instead of building a narrative around related changes
• Target audience was other rust devs, mostly viewed on r/rust, highlighted new contributors, encouraged new contributors
• Show example of blog post from 2016
• Modern monthly updates: posted each month since sept 2023
• takes 1-2 weeks to write
• include changes to Servo -> for users, but also embedders (recently), donations (encourage donations), conference talks (for developers)
• writing about changes takes the most effort
• who is our audience? need to know if we're communicating the right things effectively
• want to show that servo is alive, but now want to make servo look attractive for embedders and users
• want people to donate
• want people to contribute
• browser development has historically been pretty inaccessible compared to other kinds of programming, and servo can change that (and we have lots of contributors who don't come from any browser background)
• monthly upgdate process has changed: servo/servo.org readme contains scripts that fetch commits and support triaging into an outline, and lots of rules for how to write about changes
• the hard part: need to understand the change, who's responsible, do we want to write about it, what's different, and is it part of a bigger pattern of changes?
• need to think about how the blog post relates to a released nightly/monthly build
• is it relevant? does it affect users or embedders?
• Alice: could the PR template include the questions that you are asking about?
• Martin: In an ideal world, but in my experience many people just delete most of the template.
• Alice: Some way to get reminded of the questions would help.
• Delan: If every single PR was associated with an issue, that could be a big help.
• Jonathan: An optional section of the template might be useful. If you think the PR might be relevant for the monthly update you could fill it out?
• Delan: It could go in the template, or we could have some automation from something like the servo-highfive bot.
• Shubham: Can we rely on WebIDL to track the features?
• Delan: We do that now with the latest tooling.
• We're trying to focus on getting information we need to write narratives for more compelling posts. Tooling now tries to detect common patterns of changes like public APIs, observable platform changes, feature flags.
• To consider: ladybird blog posts focus on effect on real world websites. We don't focus on this in Servo and don't know how to get that information.
• rust-lang has a process that creates an issue for release notes that notifies people who wrote things that will be highlighted, and asks for suggested text.
• Dolphin emulator blog posts focus on a small set of really cool changes and do a deep dive
• Future plans: make sure API news for embedders is high quality, reduce current scope, recognize new contributors, highlight real world web compat?
• Simon: We talked about contributors filling out questions to help spread the work, but is there something reviewers could do to help?
• Delan: Maybe reviewers could help in similar ways? Could suggest a PR for inclusion, or help answer those questions.
• Euclid: Curious about the audience-why not on more well known platforms like twitter?
• Delan: We used to, but then Twitter got acquired and changed quite a lot, so we moved off of it.
• Rego: The TSC decided on that move.
• Euclid: Should we focus on platforms with more users?
• Delan: Bluesky is seen as the twitter successor, but we get 10x attention on mastodon than bluesky. Was true on twitter, too. Should definitely think about which platforms are most effective.
• Kagami: About real world compatibility-firefox tracks what website is broken, why it's broken, make sure it's fixed and it works again. Would help meet your goal from the beginning. Maybe servo is focusing more on WPT?
• Delan: I think historically true, since it was the easiest thing with the information we had. Do you just use your issue tracker?
• Kagami: Yes.