igrunert

If you're in Denver, Colorado you can see one in-person at The Forney Museum of Transportation.

WebKit on Windows has progressed since ~5 years ago. The gap between the Windows port and the Linux WPE/GTK ports is shrinking over time.

Every JIT tier has been enabled for JSC on Windows[1], and libpas (the custom memory allocator) has been enabled.

The Windows port has moved from Cairo to Skia, though it's currently using the CPU renderer AFAIK. There's some work to enable the COORDINATED_GRAPHICS flag which would enable Windows to benefit from Igalia's ongoing work on improving the render pipeline for the Linux ports. I go into more detail on my latest update [2], though the intended audience is really other WebKit contributors.

Webkit's CI (EWS) is running the layout tests on Windows, and running more tests on Windows is mostly a matter of test pruning, bug fixes and funding additional hardware.

There's a few things still disabled on the Windows port, some rough edges, and not a lot of production use (Bun and Playwright are the main users I'm aware of). The Windows port really needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream as they work on Orion for Windows.

[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc... [2] https://iangrunert.com/2025/11/06/webkit-windows-port-update...

The layout tests on Windows are failing at the moment due to a regression introduced a few days ago (likely https://commits.webkit.org/301043@main).

The easiest way to run WebKit on Windows is via Playwright.

A CMPXCHG16B instruction is going to be faster than a function call; and if the function is inlined there's still binary size cost.

The last processor without the CMPXCHG16B instruction was released in 2006 so far as I can tell. Windows 8.1 64-bit had a hard requirement on the CMPXCHG16B instruction, and that was released in 2013 (and is no longer supported as of 2023). At minimum Firefox should be building with -mcx16 for the Windows builds - it's a hard requirement for the underlying operating system anyway.

The "Chrome Commit Tracker" linked is a pretty interesting set of visualizations that I hadn't come across before. Makes it a lot easier to get a feel for the sizes of the various teams, and how they change over time.

https://chrome-commit-tracker.arthursonzogni.com/organizatio...

WebKit runs on Windows, the Windows port just needs work to bring it up to the level of the Linux port. I got every JIT tier enabled in JavaScriptCore [1] and enabled libpas (the memory allocator). The Windows port is moving to Skia in line with the Linux port.

Really just needs more people (and companies) pushing it forward. Hopefully Kagi will be contributing improvements to the Windows port upstream.

[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc...

Ah yeah, I see Firefox ran into that and added retries:

https://hacks.mozilla.org/2022/11/improving-firefox-stabilit...

Seems like a worthwhile change, though I'm not sure when I'll get around to it.

I recently ported WebKit's libpas memory allocator[1] to Windows, which used pthreads on the Linux and Darwin ports. Depending on what pthreads features you're using it's not that much code to shim to Windows APIs. It's around ~200 LOC[2] for WebKit's usage, which a lot smaller than pthread-win32.

[1] https://github.com/WebKit/WebKit/pull/41945 [2] https://github.com/WebKit/WebKit/blob/main/Source/bmalloc/li...

I think the author was happy to be employed by a megacorp, along with a team to push jemalloc forward.

He and the other previous contributors are free to find new employers to continue such an arrangement, if any are willing to make that investment. Alternatively they could cobble together funding from a variety of smaller vendors. I think the author is happy to move on to other projects, after spending a long time in this problem space.

I don’t think that “don’t let one megacorp hire a team of contributors for your FOSS project” is the lesson here. I’d say it’s a lesson in working upstream - the contributions made during their Facebook / Meta investment are available for the community to build upon. They could’ve just as easily been made in a closed source fork inside Facebook, without violating the terms of the license.

Also Mozilla were unable to switch from their fork to the upstream version, and didn’t easily benefit from the Facebook / Meta investment as a result.

The gap between the Windows and GTK ports is shrinking. Every JIT tier has been enabled for JSC on Windows[1], and libpas (the custom memory allocator) should get enabled soon.

The Windows port is moving from Cairo to Skia soon as well, matching the GTK port (though I think the focus is enabling the CPU renderer to start).

Webkit's CI (EWS) is running the layout tests on Windows, and running more tests on Windows is mostly a matter of funding the hardware.

There's a few things still disabled on the Windows port, some rough edges, and not a lot of production use (Bun and Playwright are the main users). It'd definitely be more work than Linux, but it's not as bad as you'd think.

[1] https://iangrunert.com/2024/10/07/every-jit-tier-enabled-jsc...

While the modern web is complicated, there's a few things working in Ladybird's favor.

Web Platform Tests (1) make it significantly easier to test your compliance with W3C standards. You don't have to reverse engineer what other engines are doing all the time.

The standards documents themselves have improved over time, and are relatively comprehensive at this point. Again, you don't have to reverse engineer what other engines are doing, the spec is relatively comprehensive.

Ladybird has chosen to not add a JIT compiler for JS and Wasm, reducing complexity on the JS engine. They're already reached (or exceeded) other JS engines on the ECMAScript Test Suite Test262 (2).

There's a big differential between the level of investment in Chromium and the other engines - in part because Chrome / Chromium are often doing R&D to build out new specifications, which is more work than implementing a completed specification. There's also a large amount of work that goes into security for all three major engines - which (for now) is less of a concern for Ladybird.

I'm confident that the Ladybird team will hit their goal of Summer 2026 for a first Alpha version on Linux and macOS. They'll cut a release with whatever they have at that point - it's already able to render a large swathe of the modern web, and continues to improve month-on-month.

(1) https://web-platform-tests.org/ (2) https://test262.fyi/

Ladybird does have another slight advantage in that it only has an interpreter for JS and wasm, instead of maintaining multiple tiers of JIT compilation for both. That choice materially reduces the surface area for exploits.

For Ladybird - Andreas Kling called out that the vast majority of "easy tests" are passing and each additional test is going to be more difficult to come by going forward.

https://www.youtube.com/watch?v=-l8epGysffQ (1 minute - 4 minute)

There are a handful of git features which work significantly better with a clean history on main. If `git blame` points at a well crafted commit, it can help bring additional context to the line in question. In addition `git log -S<string>` can be used to find when code was introduced.

Both of these features aren't very useful when they point at a "wip" or similar commit message.

By all means push lots of little commits to your branch while you're figuring stuff out, but squash and rewrite history into logical commits (usually just one) before landing the change on main.

When discussing security it's important to keep in mind the threat model.

We're mostly concerned with being able to visit a malicious site, and execute wasm from that site without that wasm being able to execute arbitrary code on the host - breaking out of the sandbox in order to execute malware. You say the only benefit is that access to the OS is isolated, but that's the big benefit.

Having said that, WebAssembly has some design decisions that make your exploits significantly more difficult in practice. The call stack is a separate stack from WebAssembly memory that's effectively invisible to the running WebAssembly program, so return oriented programming exploits should be impossible. Also WebAssembly executable bytecode is separate from WebAssembly memory, making it impossible to inject bytecode via a buffer overflow + execute it.

If you want to generate WebAssembly code at runtime, link it in as a new function, and execute it, you need participation from the host, e.g. https://wingolog.org/archives/2022/08/18/just-in-time-code-g...

> But (Safari is) the only option here that’s unsupported outside one manufacturer’s hardware.

You can use WebKit on Linux via GNOME Web (WebKitGTK), it's maintained by Igalia. Though that won't get you cross-device syncing, which is the main reason people want support on alternate hardware.

I think a big reason developers don't choose WebKit is due to the Windows port requiring significant work, and most new browsers want to support Windows.

On this thread there was a rough estimate of $1M - $2M USD to do that work. It's probably not far off the mark.

https://orionfeedback.org/d/2321-orion-for-windows-android-l...

Building an browser engine from scratch is a great exercise for validating both the specifications and the web platform tests.

For example, here's some bugs raised by Andreas Kling in the HTML spec that were found while building Ladybird:

https://github.com/whatwg/html/issues?q=is%3Aissue+author%3A...

Yep, embedding the Servo engine into the final binary. This work is sponsored by another (separate) NLnet grant:

https://nlnet.nl/project/Tauri-Servo/

Legacy Layout refers to the original system, Layout 2013. There was a second system started, Layout 2020, to address challenges with implementing parts of the CSS spec which didn't cleanly map to Layout 2013's architecture.

There's a good report in the Servo wiki from this year (authored by a group of Igalians) summarizing the differences between the two and why the decision was made to move forward with Layout 2020.

https://github.com/servo/servo/wiki/Servo-Layout-Engines-Rep...

> JavaScriptCore doesn't have WebAssembly enabled on Windows yet.

I got JavaScriptCore compiling with WebAssembly enabled yesterday, but I don't know how long it'll take to get it to actually work.

The bigger problem for Bun is that JavaScriptCore doesn't have the FTL JIT enabled on Windows [1]. It's going to be much slower than other platforms without that final tier of JIT, shows up pretty dramatically on benchmarks.

[1] https://bugs.webkit.org/show_bug.cgi?id=145366