2026 Hacking WebView features for Servo

WEH 2026 - Hacking WebView features for Servo

• GitHub issue: https://github.com/Igalia/webengineshackfest/issues/73

• URL: https://meet.jit.si/WEH2026-servo-webview

• Slides: https://niklas.merz.dev/talks/hacking-for-webviews.html#1

• Niklas: I work on standards for webviews and look at compatibility information across webview implementations. Looks like there are Servo developers here as well as people who work with webviews.

• Niklas: Webviews are for embedding, part of larger applications. Servo is promising for being one engine that runs across platforms, which could avoid compatibility problems with existing webview implementations.

• Niklas: caniwebview.com contains comaptibility data across webview implementations. Includes data about Servo! Uses bcd-collector for the data. Useful to know what's supported.

• Niklas: Frameworks like Cordova and Tauri mostly use local files, bundled into the application. Webview loads from filesystem or an API. Also use lots of injected JS and CSS. Also need two way communication, usually as JavaScript bridge that communicates with embedder.

• Niklas: Also important to share state (cookies, storage) between WebViews, persisting between runs. Need to support pausing and resuming on mobile platforms without crashing. Controlling appearance like statusbar/frame is important; Android webview has had problems with that which Cordova needed to work around.

• Niklas: Proof of concept of Servo in Cordova exists (thank you NLNet). Pretty easy to add Servo to Android app!

• Niklas: Some missing pieces—needed local HTTP server to serve files; missing two way communication (can't evaluate JS from Android API).

• Niklas: Need Java APIs for registerProtocolHandler and JS execution. Anything blocking them?

• Josh: Android embedding layer is handwritten right now, so it's easy to forget about updating it when changing the Rust embedding layer. As far as I know there's nothing stopping those from being exposed.

• Martin: If there's no way to automatically generate Java bindings...

• Jonathan: Not sure about turning the current Android code into a supported library, since it's really part of the current servoshell demo, which is not really supposed to be a supported thing.

• Niklas: I used the servoview library, which felt like a real library.

• Martin: Could be a social problem, where Android code has passed through lots of hands but nobody has said "let's have first class Java bindings".

• Martin: We do have an experimental C API, and it can be a complete wrapper. Perhaps using that as an escape hatch from incomplete Java bindings is one outcome?

• Niklas: I found servoview pretty good!

• Jonathan: The servo Rust library is the supported embedding API right now. The android library is part of the servoshell project on top of that. If we don't want to maintain two separate bindings, there may be opportunities to use things like UniFFI or Diplomat to have something that's more direct.

• Niklas: That's useful clarification. May continue adding a few missing

• (...) Martin: from my experience in webkit and js core // spidermonkey // you kind of have to do ---

• Niklas: Anything that might need consideration? It's good if you don't find any roadblocks

• : Two way communication, sometimes it made me nervous. It's easy for us to send data to the embedder because (...) serialize a bunch of stuff. The things we don't have an answer for yet is the embedding some native code that runs next to the content. Theoretically with a working (...) message, that can be referenced from the injected code ----

• Niklas: Mostly with function code, (...) register this function, pass some parameters and function data || callbacks, parsing things, not having persistent objects and so on

• : That's promisiong. Building things __ message, not having to --- is good

• Niklas: shares android webview addJavascriptInterface slide

• Niklas: It's interesting because you can define __ interface and _____ there.

• Niklas: shares android dev docs code example that's being used in Cordova (injectedObject)

• Niklas: you can call functions and pass data , I'm just a user of this API but google might now more, it's a good way to ___ (evaluate?) JavaScript.

• : Is that defining a new propert called InjectedObject?

• Niklas: Each plugin gets its new windowobject and you can call plugins on this windowObject. it might need more magic implementation for --- API but it's pretty cool this way

• Max: I can talk about how in WebKit we do this in this way | shared separate object and gets loaded into WebContent process and that shared object has access to ___ (different? ) APIs that run in the same process. For a long time WebKit exposed the DOM bindings API which lets you access native code from the code but it became unmantainable because the DOM changes very quickly and depending on ___ you compile and it changes very quickly so it's not reliable and I don't know if it exists anymore in WebKit at all.

• Niklas: I suppose that building an API like this might be more involved but I suppose that _ is a good start. I think there's an open PR, I think it might be "yours" (referring to Josh)

• Leo: Deno, experiment to use Servo, one of the main blockers is communication, solving

• Niklas: It's great to know that there's at least two people who use this API, might be a good reason to keep working on this.

• Niklas: I think talking about binary size, when I compile the ServoView library I think it was (50?) MB, what is servo doing in terms of sizing, anything I should know?

• Josh?: If you know that there is certain WebXR and several other things and it's possible to add more ___ like that. I think it's one of the biggest bang for your buck. I don't know if somebody's doing some particular investigation to binary sizes apart from now.

• ---: It's a bit difficult to do something, like some of the things like JIT in SpiderMonkey there's a || depending on your content, might be a tradeoff, but if it's okay for you it can save a lot (or not a lot), but it's significant. Strip all the debugging tools | app crashes | if you save the whole debugging tools | quite difficult to optimize, requires a huge amount of work

• Niklas: (Adding?) features with WebGL or WebGPU seems like the low hanging fruit

• ---: We enable

• Max: someone recently posted a big treemap, a boxmap of the size of all the different (diff?) sections of the binary and one big one was (ICU?) and the epersonal was stripping the tables of the ICU ___ but you're getting rid of i18n.

• ---: You can try to use system's ICU with SpiderMonkey

• Max: is there any way we can make this de default option?

• Max: Does that work properly? Because we also use __ in servo and it uses the default __ provider

• ---:

• Simon:

• ---: currently no, we've checked that

• Max: This is part of the reason why we have (or have not?) upgraded to ICU 2 in Servo

• Niklas: Is there any reason for embeddings, any challenge right now that we could assess or discuss here?

• Max: I have a question for you as someone who did use Servo for embedding. How painful was using _--- to build Servo? Build times... anything

• Niklas: I haven't compiled ___ rust project at all, but after a few times I could set it up __ contianer __ system dependencies. The compile times aren't too bad, pretty decent AMD chip, I could build it pretty nicely _____

• Erii: Should we have a Servo build container that has a lot of the ___

• Niklas: I've tried devcontainers but I think they didn't work there, but the docs pretty much gave all the info I needed

• Leo: -__ the build time I don't remember but I don't think it was pretty bad, or at least not as bad as Deno can be

• Erii asks --- a question

• Niklas: You've mentioned OpenHarmony a few times, I'm pretty interested as a WEB__CG? guy.

• --- we try to keep things upstream but there's some thing that are difficult to keep upstream, it's kind of essential but not a priority anymore, but I didn't work on that part so I don't know the details. Mostly Works pretty well (can't hear part of this, he's speaking a bit quieter)

• ---: Niklas: Local files and origins might be a good example to go through and see how I can solve this using Servo, if it's exposed to java we can use it. here. ___ protocol doesn't work here anymore and it's interesting to look at the comparison between Android and iOS. shows loading local files APIs slide

• Niklas: how we can do it in servo, register your own custom domain or some default ones, then when you register your own custom domain then you can have your own_ to your domain and it only accepts the requests to this domain ___ you can register custom schemes just like my example then you can basically in the native world, inside the webview anything that calls the custom scheme it __ post and get the content. I've personally used the iOS __ to get the proxy, in Android I cannot do this. My question to Servo would be how could that do, once it's available in the Android world with the java API

• Josh?: We can use the protocol handler. I think we have exapmples--- is (solar? ) different

• Max: _--- we also have a registered protocol handler, the implementation that does the same thing

• Josh: the reason for this is that the protocol handler we have does this, and it's a matter of thinking how to expose it to the java side

• Max: using the resource I think you can intercept all the requests to that domain

• Josh: The resource handler is that for the limited list.

• Josh: We can intercept arbitrary requests, with that I guess you can use

• Josh: do we support stopping the request and giving a response back?

• Max: I think you're right, it's a matter of exposing this functionality for the API

• Niklas: It's great to hear that all I need for my usecase is available, I just need documentation.

• Niklas: we can check on another thing basically state sharing, or state at alll. It has all these things and sync between windows or webview instances. iOS cookie persistence is really vague and you can't really rely on it, I wonder how Servo handles this.

• Josh: It might not work on android (that's a good point).

• Max: (missing a bit of dialogue from Max because plasmashell froze)

• Max: "cookies, if you delete them", "this is definitely one that needs more work". Also our cache and cookies I think they need to be modified to support isolated store.

• Josh: All browsers in the same servo instance will share the same cookies and cash, we intend to move to a model with independent state, but I model with webviews that will use the same isolation

• Niklas: We can close early after one hour, been thinking about ___ and embedding, we can use the time to chat more about embedding and if you wanna keep in touch you can find my email and check out this talk and feel free to join the WV community group.

• Niklas: Last time I tried everything works!

• Woo from the crowd :)

• --I have a question in general requirements for webview, which android uses and is it specced --

• Niklas: reason why wvcg exists if

• Niklas: reason why wvcg exists is we tried to solve stuff, we've tried doing the same thing in different ways, and there is no common, it's been bugging me

• Niklas: ---- look together to see what is secure and what is not secure and

• Jan: this is about in the native layout. Electron, that's basically what I'm working on having a baseline to have webview text that still have secure context inside the webview and make a prototype for iframes. It should be reachable I don't know how much we hacked into this

• Josh: webbeef maintains a fork which contains a lot of patches but (implementation isn't there yet?)

• Jan: doesn't sound like immediately on the horizon, putting it out there

• Niklas: just watched the same (/clink on tar/?) as you did but it's ____

• ---: At least from the China ecosystem both the hybrid and the bigger chunk of the web compared to the real web browser usage I think there was a mini app working group

• Niklas: working group and community group there has been some standards written but it's hard to convince some of the --- standard, diverging tags and it's hard to come to consensus on this, we have existing existing implementations __ and yeah

• Sohan: Just curious of the servo sizes of regular webviews like how does it compare to Chromium or WebKit or how does it compare to Microsoft's WebView¿2

• Manuel: Like WebView2?

• ---: smaller than chromium but the size keeps growing, the clear trend is visible.Yeah, we need to see how we imp lement the same features. We are smaller, yes but we'll see.

• Max could be actually Martin in my notes (sorry!)

• ---: is

• Niklas: __ this whole open source umbrella, we have to figure out if we do anything in the framework,|| liable for what's gone wrong and somebody can choose to ignore or take care of it

• ___ convincing people to use Cordova, hopefully I don't

• Niklas: So we would never do something ___ as a group there's no reason to do it and nobody paying for that. Cordova as of today is a bundling engine, we're putting some native code around it and some Apache code, so this is business as usual from my perpective at least. Where are you coming from, (the question)

• _____: If I shipped this I would need to do the CRA

• Niklas: I see it. This is a whole different beast as it's considered by the CIA and has obligations.

• : First party

• Niklas: if you don't use it for browsing the web but someone ___ from the linux foundation you ___ obligation to be reliable. I get your point that it would be interesting to make it CIA compliant to advertise it more. As we learned today in the breakout session once we have this vertical standard for browsers --- CIA compliant it's a presumption of third-party authored.

• ___: container solution for fixing ---

• :

• Person with the three dashes is Jonathan mostly, latter ones was Sohan

----------------- jdm's notes that got lost while offline

• Niklas: I work on standards for webviews and look at compatibility information across webview implementations. Looks like there are Servo developers here as well as people who work with webviews.
• Niklas: Webviews are for embedding, part of larger applications. Servo is promising for being one engine that runs across platforms, which could avoid compatibility problems with existing webview implementations.
• Niklas: caniwebview.com contains comaptibility data across webview implementations. Includes data about Servo! Uses bcd-collector for the data. Useful to know what's supported.
• Niklas: Frameworks like Cordova and Tauri mostly use local files, bundled into the application. Webview loads from filesystem or an API. Also use lots of injected JS and CSS. Also need two way communication, usually as JavaScript bridge that communicates with embedder.
• Niklas: Also important to share state (cookies, storage) between WebViews, persisting between runs. Need to support pausing and resuming on mobile platforms without crashing. Controlling appearance like statusbar/frame is important; Android webview has had problems with that which Cordova needed to work around.
• Niklas: Proof of concept of Servo in Cordova exists (thank you NLNet). Pretty easy to add Servo to Android app!
• Niklas: Some missing pieces—needed local HTTP server to serve files; missing two way communication (can't evaluate JS from Android API).
• Niklas: Need Java APIs for registerProtocolHandler and JS execution. Anything blocking them?
• Josh: Android embedding layer is handwritten right now, so it's easy to forget about updating it when changing the Rust embedding layer. As far as I know there's nothing stopping those from being exposed.
• Martin: If there's no way to automatically generate JAva bindings...
• Jonathan: Not sure about turning the current Android code into a supported library, since it's really part of the current servoshell demo, which is not really supposed to be a supported thing.
• Niklas: I used the servoview library, which felt like a real library.
• Martin: Could be social problem, where Android code has passed through lots of hands but nobody has said "let's have first class Java bindings".
• Martin: We do have an experimental C API, and it can be a complete wrapper. Perhaps using that as an escape hatch from incomplete Java bindings is one outcome?
• Niklas: I found servoview pretty good!
• Jonathan: The servo Rust library is the supported embedding API right now. The android library is part of the servoshell project on top of that. If we don't want to maintain two separate bindings, there may be opportunities to use things like UniFFI or Diplomat to have something that's more direct.
• Niklas: That's useful clarification. May continue adding a few missing APIs to existing bindings until there's a better supported future.
• Jonathan: Currently main desktop: macOS, Windows, Linux. Windows is less well supported due to less usage. Android is only built in CI; there are no automated tests, and we test manually before releasing each month. OpenHarmony has tests in CI, which helps Android because it shares backend. Also FreeBSD support, but not built in CI. iOS has not been investigated, but would be nice.
• Niklas: Would love iOS, but understand the challenges there.
• Niklas: Anything from the list of hybrid app requirements that Servo is missing?
• Martin: There's a concept called isolated worlds, which allows injecting script into a page that is isolated from the actual page content (no sharing globals). Important for app developers so that the page can't interfere with privileged app scripts.
• Josh: We can copy Gecko's implementation, but it's outside of SpiderMonkey unfortunately.
• Josh: For two way communication, do we just need the equivalent of two-way postMessage that serializes plain old data, or do apps expect things like sending DOM nodes back and forth?
• Niklas: Interesting question. Defining JS interfaces might be interesting, but I think most developers are happy with sending data.
• Martin: In webkit, you have to build a shared object that gets loaded into the web content process, and that object has access to different APIs than code that runs in the main process. Webkit used to have a DOM bindings API from native code but it became unmaintainable in webkitGTK, so don't know if it still exists.
• Niklas: Basic javascript evaluation might be enough for a start.
• Leo: Deno landed a way to select a webview backend, and there's an experimental backend for Servo. The missing postMessage is the thing preventing us from shipping it right now.
• Niklas: Binary size is around 50mb. It's ok, but is there a way to reduce that? What is Servo doing with that?
• Josh: It's possible to disable engine features if you know that you don't need to support it, like WebGPU, WebXR, etc.
• Jonathan: Tradeoffs exist like disabling SpiderMonkey JIT, which can be a significant saving. OpenHarmony team has looked into this problem. Stripping debug info helps (we do that in our releases), but then it's harder to handle crashes.
• Niklas: Disabling features sounds like low hanging fruit. Is that a big saving?
• Jonathan: Single digit megabytes.
• Martin: Someone posted a binary size analysis and the biggest possible saving was from ICU. It's a big cut if you know you won't support international text.
• Jonathan: Could work on supporting a SpiderMonkey option to disable ICU and use the system ICU instead, if the system is new enough. That's like 15 mb.
• Simon: Any chance we have two copies of ICU from SpiderMonkey and Servo?
• Jonnathan: No, we checked that.
• Martin: One reason we haven't upgraded to ICU v2.
• Niklas: Anything else we need to know?
• Martin: Question for you—how painful was it to build Servo? Build time, dependencies?
• Niklas: Bit painful because I had never compiled a Rust project at all. Managed to set up a container and run it within there, since it didn't work on the host system. Compile times weren't bad since my machine is new enough.
• Eri: Should we have a Servo build container?
• Jonathan: We have a devcontainer now.
• Niklas: Tried devcontainer and it didn't work there, but documentation gave me everything I needed.
• Leo: I built Servo and it was trivial. Deno is used to building Rust. I'm used to long build times and Servo wasn't bad.
• Niklas: Is OpenHarmony using Servo for embedding or an app?
• Jonathan: Mainly embedding, and have some forks with things that haven't been upstreamed like a rough postMEssage implementation.
• Niklas: Loading local files and origins—file:// doesn't work. Android and iOS do different things—register domains vs. URL schemes. Intercept requests to the domain/URL and provide the file content.
• Josh: We have a ProtocolRegistry for particular schemes and get a callback for requests to a scheme, it's just not exposed to Java yet.
• Martin: Also we can intercept requests...
• Josh: Oh right, that exists too. Again, just need to be exposed.
• Niklas: That's great news. Sounds like we just need documentation for these use cases.
• Niklas: How about state sharing?
• Martin: We have cookies, and they are persisted in a JSON file.
• Josh: But maybe not on Android.
• Martin: Persistence in Servo neds some love. Need to differntiate between cache directory and config directory so deleting the cache doesn't delete data you care about.
• Josh: All webviews currently share same state. Intend to move to a model where they're isolated by default, but can imagine a way of forcing them to share state.
• Martin: There's probably a sizable project that involves introducing that and fixing the persistence.