Fuzzing Ladybird with tools from Google Project Zero

Andreas Kling — Sat, 16 Mar 2024 11:01:49 GMT

While Ladybird does an okay job with well-formed web content, I thought it would be useful to throw some security research tools at it and see what kind of issues it might reveal. So today we’ll be using “Domato 🍅”, a DOM fuzzer from Google Project Zero, to stress test Ladybird and fix some issues found along the way.

The way this works is that Domato generates randomized web pages with lots of mostly-valid but strange HTML, CSS and JavaScript. I then load these pages into a debug build of Ladybird and observe what happens.

Domato generates HTML pages of roughly 500 KiB in size, filled with “interesting” JS, CSS and HTML to surprise and delight your browser engine!

The Domato README boasts a ton of bugs discovered in all major browsers, so I have no doubt it will find some in ours as well. Here we go!

Issue #1: inside

Unsurprisingly, it took less than a second to find the first issue! The output produced by Domato is actually 562 KiB, but I was able to reduce it to the following:

I’ve compiled Ladybird with UBSAN (Undefined Behavior SANitizer) for this test, and I get the following very helpful trace output:

LibWeb/HTML/HTMLTableCellElement.cpp:55:36: runtime error: member call on null pointer of type 'Web::DOM::Node'
#0 0x7e9bfa1610dd in table_containing_cell LibWeb/HTML/HTMLTableCellElement.cpp:55:36
#1 0x7e9bfa1610dd in Web::HTML::HTMLTableCellElement::apply_presentational_hints(Web::CSS::StyleProperties&) const LibWeb/HTML/HTMLTableCellElement.cpp:101:33
#2 0x7e9bf97c22d1 in Web::CSS::StyleComputer::compute_cascaded_values(Web::CSS::StyleProperties&, Web::DOM::Element&, AK::Optional, bool&, Web::CSS::StyleComputer::ComputeStyleMode) const LibWeb/CSS/StyleComputer.cpp:1448:17
#3 0x7e9bf97e5899 in Web::CSS::StyleComputer::compute_style_impl(Web::DOM::Element&, AK::Optional, Web::CSS::StyleComputer::ComputeStyleMode) const LibWeb/CSS/StyleComputer.cpp:2231:5
#4 0x7e9bf97e447e in Web::CSS::StyleComputer::compute_style(Web::DOM::Element&, AK::Optional) const LibWeb/CSS/StyleComputer.cpp:2202:12
#5 0x7e9bf9a7e60c in Web::DOM::Element::recompute_style() LibWeb/DOM/Element.cpp:575:64

It’s a good old-fashioned null pointer dereference!

As it turns out, we’ve implemented and elements with the assumption that there’s always a

somewhere above it in the DOM tree. We probably believed this because the following is not allowed by the HTML parser:

If you load the above markup in a spec-compliant browser, it will create a single element with nothing inside it.

However, when creating DOM nodes manually using JavaScript API, you can break some of the rules that the parser has to follow, and indeed put a

inside an !

Here’s the buggy function:

HTMLTableElement const& table_containing_cell(HTMLTableCellElement const& node)
{
    auto parent_node = node.parent();
    while (!is(parent_node))
        parent_node = parent_node->parent();
    return static_cast(*parent_node);
}

It’s used to implement the ancient feature where

and

applies CSS border and padding to each table cell, and not just the table box itself.

The fix is simply to stop assuming that

and

elements always have a containing

 in the ancestor chain. We don’t need the table_containing_cell helper but can instead simply replace this:
auto const& table_element = table_containing_cell(*this);
With this:
auto const table_element = first_ancestor_of_type();
if (!table_element)
    return;
And we’re done with issue #1! (Fix committed here.)
Issue #2: Assigning window event handlers in detached DOM
We continue executing the fuzzer and once again, within less than 1 second, we hit a new problem. The Domato output is 472 KiB, but it whittles down to this:
When opened in Ladybird, we fail like so:
VERIFICATION FAILED: m_ptr at LibJS/Heap/GCPtr.h:174
#1  JS::GCPtr::operator* at LibJS/Heap/GCPtr.h:174
#2  Web::DOM::Document::window at LibWeb/DOM/Document.h:320
#3  Web::HTML::HTMLBodyElement::global_event_handlers_to_event_target at LibWeb/HTML/HTMLBodyElement.cpp:104
#4  Web::HTML::GlobalEventHandlers::set_onblur at LibWeb/HTML/GlobalEventHandlers.cpp:24
#5  Web::Bindings::HTMLElementPrototype::onblur_setter at LibWeb/Bindings/HTMLElementPrototype.cpp:1153
The reason things go wrong here is due to the special behavior of onfoo event handler attributes on the  element. For compatibility with ancient web content, assignments to document.body.onfoo must forward to window.onfoo. However, documents created via DOMParser do not have a window object!
It turns out we’ve misunderstood this detail in our implementation, and structured our internal object model as if every document always has a window. Oops!
The fix is to make Document::window() return a nullable value, and then handle null in a bajillion places. When assigning document.body.onblur in a window-less document, we now simply do nothing, same as other browsers.
(Fix committed here.)
Issue #3: Infinite recursion in SVG 
Modern browsers have to support SVG both inline in HTML, and also as an external image format. This adds a whole host of new edge cases and interesting interactions.
For example, SVG allows declaring gradients that reference other gradients to inherit their colors. As it turns out, we hadn’t considered the case where a gradient references itself:
The SVG above would cause our implementation to loop forever as it attempted to follow the chain of referenced gradients. Oops, indeed!
The obvious fix is to stop following the chain of linked gradients if the current gradient references itself. However, that doesn’t cover reference cycles that span multiple steps like so:
To properly handle cyclical references, we have to keep track of all the gradients we’ve visited, and stop following the chain if we encounter a gradient we’ve already visited before.
Curiously, Firefox actually complains about these kind of gradients in their developer console:
(Fix committed here.)
Issue #4: Accessing the window properties of a removed iframe
This one is interesting:

The above test would crash like this:
LibWeb/HTML/WindowProxy.cpp:161:136: runtime error: reference binding to null pointer of type 'const BrowsingContext'
#0 0x77367675cadf in Web::HTML::WindowProxy::internal_get(JS::PropertyKey const&, JS::Value, JS::CacheablePropertyMetadata*) const LibWeb/HTML/WindowProxy.cpp:161:5
#1 0x773670c4fcca in JS::Bytecode::get_by_id(JS::VM&, AK::DeprecatedFlyString const&, JS::Value, JS::Value, JS::Bytecode::PropertyLookupCache&) LibJS/Bytecode/CommonImplementations.h:105:18
#2 0x773670c182d5 in JS::Bytecode::Op::GetById::execute_impl(JS::Bytecode::Interpreter&) const LibJS/Bytecode/Interpreter.cpp:1088:28
#3 0x773670bc8e1f in execute LibJS/Bytecode/Op.h:1898:9
#4 0x773670bc8e1f in JS::Bytecode::Interpreter::run_bytecode() LibJS/Bytecode/Interpreter.cpp:409:38
As it turns out, this is actually a bug in the HTML spec! When an iframe is removed from the DOM, its content document is detached from its browsing context. However, when getting or setting a property on a window object, we run a spec algorithm called "check if an access between two browsing contexts should be reported" which inspects the browsing context of the “accessor” and “accessed” window. The spec incorrectly assumed that both windows have an associated browsing context at the time of property access.
I’ve opened an issue against the HTML spec, and patched this in Ladybird in the meantime by adding a null check.
Finding spec bugs is actually one of my favorite things while working on Ladybird. It allows us to improve the specs for everyone by submitting a bug report or fix.
(Fix committed here.)
Issue #5: Infinite looping in Element.before()
When opening the next page, it just wouldn’t finish loading. It just sat there chewing 100% CPU.
Here’s the reduction:

This was a mistake in the implementation of before(), which has to find the first preceding sibling of 
 that isn’t one of its arguments (i.e  in this case.) We had the following loop mistake in the implementation:
while (auto previous_sibling = node->previous_sibling()) {
    // check if previous_sibling is one of the arguments
}
The problem here is that we kept fetching node->previous_sibling, instead of continuing to follow the sibling chain via previous_sibling->previous_sibling.
Here’s how I fixed it:
for (auto sibling = node->previous_sibling(); sibling; sibling = sibling->previous_sibling()) {

    // check if previous_sibling is one of the arguments

}
(Fix committed here.)
Conclusion
This can probably go on for quite some time, so let’s call it a day. We found five real bugs, one of which was a spec bug, and were able to fix all of them.
Even though things went basically as I expected, it’s still quite interesting just how quickly we fall apart when confronted with strange and unexpected inputs. Fuzzers like Domato are an amazing resource for anyone who wants to make their software more robust.
The next step here will be to get Ladybird to the point where we can handle a sustained onslaught of fuzzed inputs. And once it’s reasonably stable, we can start running it automatically in the cloud somewhere, and hopefully shake out even more issues.


Welcoming Shopify as a Ladybird sponsor
Andreas Kling — Wed, 28 Jun 2023 04:45:32 GMT
Hello friends!
I'm super excited to announce that Shopify has stepped up to become the first ever corporate sponsor of the Ladybird browser project, generously contributing $100,000 USD!
Here's a quote from Mike Shaver, Distinguished Engineer at Shopify, on why they decided to back us:
“Ladybird is a love-letter to the web, and proof that open technologies enable innovation by organizations of all sizes. Shopify grew up on those technologies, and proudly contributes to them. We’re excited to add Ladybird to the set of projects we support.”
As you can imagine, I'm pretty hyped! Not just about the financial support, but also about the massive vote of confidence in what we're doing. Of course, this accomplishment isn't mine alone. It's a testament to the dedication and hard work of our entire team who put so much of their time and love into Ladybird. I'm so incredibly proud of the work everyone is doing!
In a time where big tech companies are giving up on their own browsers and consolidating on Chromium, it's up to hackers & web enthusiasts like us to reintroduce diversity into the browser market. And that's exactly what we hope to do with Ladybird: to create an independent browser from scratch, free of 3rd party code, in classical open-source spirit.
A massive thank you to Shopify for believing in Ladybird! I can't wait to put the funds to work and see how far we can propel this thing. :)
Follow @ladybirdbrowser on Twitter for updates and please reach out if you're interested in getting involved. Thanks for reading!


15-minute habit: Magyarul tanulok! (I am learning Hungarian)
Andreas Kling — Sat, 29 Apr 2023 08:21:54 GMT
4 weeks ago I wrote about taking on a 15 minute daily cleaning habit together with my wife. It has been tremendously effective and our home looks like we just moved into it: everything is clean and sparkly, and it even smells nice. And all it takes is 15 minutes per day!
In the wake of this astonishing success, I thought I’d try adding a second 15-minute-per-day habit, to see if I can stack these things.
The first thing that came to mind was something I’ve been meaning to do for years, but always kept making excuses about and postponing: I want to learn my wife’s native language of Hungarian.
Katalin and I have been married for over 10 years, and she has learned my language (Swedish), but I haven’t learned hers. Even though we live in Sweden, and her speaking Swedish has more obvious practical value, this has always felt unfair to me. At the same time I found it hard to take any real steps towards actually doing it.
For the last 7 days, I’ve been learning Hungarian for 15 minutes per day. I’m using the Duolingo app, and it’s been great. The ratio of “learning new words” to “repeating things I already learned” is extremely well-tuned, and it seems like things actually stick to my brain. Furthermore, the Duolingo lessons only take a few minutes each, so I can squeeze in a bunch every day. This makes it feel like I’m always moving forward, which is great.
This is my first time learning a new language since I was a teenager, and it feels both intimidating and exciting at the same time. I’m really looking forward to connecting with Katalin on a deeper level, and reading some of the books she loved as a child.
Have you learned a language as an adult? Maybe even Hungarian? I’d love to hear your experience and any tips you might have in the comments below :^)
Viszontlátásra! (Goodbye)


Running Ladybird with foreign GUI toolkits
Andreas Kling — Tue, 25 Apr 2023 12:55:03 GMT
One of my long-term goals for the Ladybird web browser is to make it feel native on every platform it runs on. We’re far from there today, and it’s going to take considerable effort to get there.
However, this week I’ve made one huge step forward in this area. Let me tell you about it!
Born in the fires of SerenityOS
SerenityOS, the birthplace of Ladybird, is a mostly-closed environment. We control all the APIs from bottom to top, and this has given us a lot of flexibility in building a cohesive system.
Everything event-driven in the system (GUI applications, system services, the CLI shell, …) builds on top of Core::EventLoop, Core::Timer and Core::Notifier.
Let’s look at a simple example of Core::EventLoop so we know what we’re talking about:
{
    Core::EventLoop event_loop;

    auto timer = Core::Timer::create_single_shot(3000, [&] {
        event_loop.quit();
    });
    timer->start();

    event_loop.exec();
}
In the example above, we create an event loop and start a single-shot timer that will fire 3 seconds from now and quit the loop. Then we enter the loop by calling exec(). After 3 seconds, exec() will return. Basic stuff that any event loop supports.
The trouble with event loops is that every major GUI toolkit has its own event loop, and their UI widgets typically only work when combined with their own event loop. Qt has QEventLoop, Gtk+ has the GMainLoop, macOS has the CFRunLoop, etc…
In other words, to look native on other platforms, we have to run their event loops.
Attempt 1: abstraction at the wrong layer
Ladybird started life as a Qt wrapper around LibWeb, and as such, the path of least resistance was using a QGuiApplication in its main function.
I added an interface to LibWeb called Web::Platform::EventLoopPlugin which allowed you to override the various operations that LibWeb would normally do on the Core::EventLoop.
The interface looked something like this:
class EventLoopPlugin {
public:
    virtual void spin_until(JS::SafeFunction condition) = 0;
    virtual void deferred_invoke(JS::SafeFunction) = 0;
    virtual NonnullRefPtr create_timer() = 0;
    virtual void quit() = 0;
};
And it worked out pretty well! LibWeb code was updated to stop calling Core::EventLoop and instead calling the installed EventLoopPlugin. Ladybird got its own plugin that proxied to Qt APIs and all was well…
… Of course, now we also had to patch LibIPC, which LibWeb uses under the hood to communicate between processes. IPC::Connection uses Core::EventLoop::deferred_invoke() to invoke callbacks some time in the future. These needed to be rerouted to the Qt event loop in Ladybird, so I added a new IPC::DeferredInvoker interface:
class DeferredInvoker {
public:
    virtual void schedule(Function) = 0;
};
Ladybird installs its own DeferredInvokerQt on its IPC::Connection objects, which bundles the callback in a QTimer::singleShot() and we’re back on track…
… Well, we’re also not waking up when sockets become readable. LibWeb and our other libraries often use Core::Notifier which invokes a callback once a specific file descriptor becomes readable/writable. Since we’re in the Qt event loop, there’s no Core::EventLoop to notify our notifiers, and nothing happens.
No problem, we’ll just set up a helper QSocketNotifier for each Core::Notifier in Ladybird. We ended up with this thing to equip each IPC client with the necessary assistance:
template
void proxy_socket_through_notifier(ClientType& client, QSocketNotifier& notifier)
{
    notifier.setSocket(client.socket().fd().value());
    notifier.setEnabled(true);

    QObject::connect(¬ifier, &QSocketNotifier::activated, [&client]() mutable {
        client.socket().notifier()->on_activation();
    });

    client.set_deferred_invoker(make());
}
Ladybird had to do this manually for anything at any level in the stack that wanted to use a Core::Notifier, but at least now things were working.
Attempt 2: abstraction at the right layer
Over time, as work continued on the browser, new things would sneak in that used LibCore without consideration for Ladybird and its Qt event loop. After playing whack-a-mole with these issues for months, I finally decided to do something about this.
The solution: Instead of patching everyone’s calls to go somewhere other than LibCore, let’s make LibCore pluggable and allow clients to install a different backend for the event loop.
I added a new interface called Core::EventLoopImplementation and made Core::EventLoop a simple wrapper around calls to an underlying implementation object.
class EventLoopImplementation {
public:
    enum class PumpMode {
        WaitForEvents,
        DontWaitForEvents,
    };
    virtual size_t pump(PumpMode) = 0;
    virtual int exec() = 0;
    virtual void quit(int) = 0;
    virtual void wake() = 0;
    virtual void deferred_invoke(Function) = 0;
    virtual int register_timer(Object&, int milliseconds, bool should_reload, TimerShouldFireWhenNotVisible) = 0;
    virtual bool unregister_timer(int timer_id) = 0;
    virtual void register_notifier(Notifier&) = 0;
    virtual void unregister_notifier(Notifier&) = 0;
};
(The API is actually a little more complex than that, due to esoteric features only used in SerenityOS, but the above gives you an idea of the interface.)
Our old event loop has moved into a new EventLoopImplementationUnix class which is what we use on SerenityOS by default. This is also portable to other Unix-like systems and runs fine on Linux, macOS, etc.
Ladybird gets its own EventLoopImplementationQt class, which translates the various LibCore concepts to Qt equivalents. Core::Timer gets a QTimer, Core::Notifier gets a QSocketNotifier, etc.
Libraries no longer need to think about what event loop they might be running on. As far as they care, it’s Core::EventLoop.
What’s so great about this?
On the surface, this is a pretty pedestrian refactoring. However, what we’ve achieved is actually very important in the long term:
There’s now a blueprint for integrating Ladybird with other event loops. Wanna run on top of Gtk+? Implement EventLoopImplementationGlib! macOS? You’ll need an EventLoopImplementationCF.
Once you get those pieces into place, the rest of our browser stack should (in theory!) hum along nicely on top of it. In fact, one might even consider this a first step towards bringing other SerenityOS applications to other platforms as well. :^)
Here’s what the documentation for QEventLoop looks like in Ladybird today!


Resizing the Mac App Store: a tale of regret & redemption
Andreas Kling — Wed, 19 Apr 2023 15:34:06 GMT
In 2013, I worked on the Safari/WebKit team at Apple. One day, I was assigned a bug from the Mac App Store team. They were developing a new version of the store app, built almost entirely on web content, and it was really sluggish when resizing.
I’d been on the team for a few years at that point, and while I was new, I felt confident that I could help the App Store folks improve performance somehow.
Here’s what the app looked like at the time:
Investigating the issue
As with any performance issue, I fired up Instruments and captured a time profile while resizing the App Store window.
The profile showed us spending most of the time in three subsystems:
Layout
Style recalculation
JavaScript execution
I was pretty comfortable with style recalculation in WebKit (much thanks to great mentorship from Antti Koivisto), so I decided to start looking there. Over the next few weeks, I found a number of inefficiencies and constructed optimizations for them.
My optimizations
I went through the WebKit history and found the various things I did to make it faster. In retrospect, I was pleased to discover that they were generally useful optimizations and not specific to the app store use-case.
Let’s go down memory lane and look briefly at the optimizations I added:
Don't check for @media rules affected by viewport changes in every layout.
Before this change, WebKit would synchronously re-evaluate media queries for every step of a resize, instead of allowing them to coalesce with the next visual update.
When updating geometry, send JavaScript resize before layout/paint.
The App Store content had a resize event listener in JavaScript that would sometimes make changes to the page layout. If I recall correctly, it was switching between displaying 3 and 4 apps per row.
Before this change, while resizing the window, WebKit would first relayout the page, then dispatch the resize event. If the event handler did something that changed the layout, we’d do another relayout, and then finally paint the results.
By dispatching the resize event first instead, we only do one relayout, even if the event handler does something that invalidates layout!
Setting an inline style property to "" shouldn't cause style recalc unless the property was present.
Before this change, doing element.style.someProperty="" would always trigger a style recalculation, even if someProperty was not present in the element’s inline style.
CSS attribute selectors cause unnecessary style recalc when setting attribute to same value.
Before this change, setting an element attribute to the same value it already had would cause a style recalculation if there were attribute selectors matching that attribute.
An optimization that didn’t work out
I also attempted this one, but we had to revert it because it broke real websites:
Throttle resize events during live window resize.
The idea was to only send resize events at most every 0.2 seconds while the window was being actively resized. It was a nice idea, but as is often the case with browser optimizations, it broke real world content so we couldn’t do it.
It got better, but still too laggy
While my optimizations did improve performance, they only added up to something like a 20% speed-up in total. Good, but not great. And the App Store was still noticeably laggy.
I had managed to reduce the amount of style recalculation happening, but I hadn’t made much of a dent in layout, and that’s where most of the time was disappearing now.
The App Store content was using heavily nested CSS flexbox layouts (actually the old pre-specification -webkit-box version!), and I vividly remember profiling it and staring at a tree full of WebCore::RenderDeprecatedFlexibleBox functions.
While my comfort zone overlapped with style recalculation, anything layout related was strictly outside of it. This wasn’t unique to me, most of the people working on WebKit were uncomfortable with layout code. Ever since I joined the project, I’d heard people talk about layout (and those who worked on it) as something impossibly, almost mythologically, complicated.
I had totally bought into this mythology, and now that I was staring at a layout performance bug, I felt paralyzed. “There’s no way I can solve this, it’s layout!”
Still I picked at the profiles and poked around the code a bit for another week or so, but I wasn’t really making an effort to understand how it worked.
Rescued by Dave Hyatt
I forget exactly how it happened, but I think at some point I told my manager I was unable to make any more progress on the issue.
They asked one of the layout experts, Dave Hyatt, to take a look. I tried explaining what I had learned to Dave, but in truth I didn’t have much of value to offer. He went off to investigate the issue on his own.
After a few days, Dave had devised a set of optimizations that dramatically improved performance:
Improve the performance of RenderDeprecatedFlexibleBox
The main improvement came from deferring the painting of flex items until they had been placed in their final position by the flex layout algorithm. This avoided a huge chunk of work, and we could finally resize the App Store with much less lag.
At the time, I didn’t understand his changes. It may as well have been magic! And instead of trying to learn from this experience, I quickly moved on to issues where I felt more comfortable.
From regret to redemption
Afterwards, I felt bad about this for a long time. I was angry at myself for not being able to figure out a solution, and I decided to stay away from layout code from then on.
I spent the next few years all over WebKit (and deeper in the macOS/iOS software stacks) to improve browser performance, and learned thousands of things, but none of them about layout.
Flash forward to today, where I’ve implemented most of CSS flexbox (and many other layout modes) myself while working on the new Ladybird browser.
I’ve got a decent grasp on CSS layout, and I could definitely debug that App Store problem and improve their performance! Of course, it’s 10 years too late, but I feel good knowing I’ve repaired something that once made me feel so inadequate.
I don’t think I’ve ever mentioned this, but before I decided to start building a new browser, having to deal with layout was the main reason I kept putting it off. I was afraid that if I start building a browser, I’ll eventually get stuck on the mythologically impossible layout part, and fail.
Thankfully I decided to face my fears, and I’ve spent the last couple of years doing my best to help others not mythologize any aspect of software development by tackling “impossible” projects in public.
In retrospect, I should have ignored the mythologizing and made an effort to understand CSS layout sooner. It’s amazing fun once you get the hang of it!
If you’re interested, come hack on Ladybird with us in the SerenityOS project!
Thanks for reading! Subscribe for free to receive new posts and support my work.



Implementing an underspecified CSS feature (flexbox gaps)
Andreas Kling — Mon, 17 Apr 2023 05:57:34 GMT
While the CSS specifications have come a long way in recent years, it is still the case that some features are vague and underspecified.
I’ve recently implemented one such feature in Ladybird, and I thought it could be interesting to share how it went.
The feature in question is support for gaps (sometimes called “gutters”) between boxes in a CSS flex layout.
Here’s a quick example so you know what we’re talking about:
                        
    well       
    hello      
    friends    
History of gaps in CSS
If I’ve understood things correctly, gaps were first added to CSS with the CSS Grid Layout module.
The original grid properties were called grid-column-gap and grid-row-gap but eventually someone realized that this feature could be useful in other layout modules as well, and two aliases were added: column-gap and row-gap.
Gaps are now specified in CSS-ALIGN-3, under “Gaps Between Boxes”.

    well
    hello
    friends
Okay, let’s read the spec...
Here’s what CSS-ALIGN-3 says about gaps between items in a flex layout:
When applied to the main axis (e.g. column-gap in a row flex container), indicates minimum spacing between items (as if an additional fixed-size margin were inserted between adjacent flex items in a single line).
When applied to the cross axis (e.g. row-gap in a row flex container), indicates minimum spacing between adjacent flex lines.
The flex layout spec itself, CSS-FLEXBOX-1, does not mention gaps at all.
In other words, those two measly sentences from CSS-ALIGN-3 are everything we have to go on for implementing this feature!
Implementing it in Ladybird
Based on the text from CSS-ALIGN-3 above, here’s how I ended up implementing gaps in Ladybird’s LibWeb engine:
First, I defined two helper concepts: main gap and cross gap which are direction-dependent aliases for the column-gap and row-gap properties. These are important because the flex layout algorithm abstracts away the horizontal/vertical axes in favor of main/cross axes.
Then, I made the following adjustments to the flex layout algorithm:
When collecting flex items into flex lines and flex-wrap is not no-wrap, we now take the main gap into account when deciding whether to begin a new flex line after an item.
When resolving flexible lengths, we now include the main gap between items when calculating the sum of outer hypothetical sizes and sum of outer flex base sizes.
When handling ‘align-content: stretch’, we now include the cross gap between items when calculating the sum of flex line cross sizes. (Fun fact: I actually discovered while writing this post that this step was necessary!)
When distributing any remaining space, we now include the main gap between items when calculating the amount of used space in the main axis. We also use the main gap as an additional offset when aligning flex items along the main axis.
When aligning all flex lines, we now include the cross gap between flex lines when calculating the sum of flex line cross sizes. We also use the cross gap as an additional offset when aligning flex lines along the cross axis.
When calculating the flex container’s intrinsic main size, we now include the main gap between items when calculating the largest sum of contributions within each flex line.
When calculating the flex container’s intrinsic cross size, we now include the cross gap between flex lines when calculating the sum of flex line cross sizes.
While I’m not completely confident that these adjustments match exactly how other browsers behave, the various test cases I’ve constructed do render identically in Ladybird, WebKit, Blink, and Gecko.
Before & After
Here’s what we looked like before:
And here’s what we look like now:
When will flexbox gaps be properly specified?
There’s an open issue against CSS-FLEXBOX-1 about updating the layout algorithm to take gaps into account. It appears that the work has been deferred to CSS-FLEXBOX-2, which (as far as I can tell) is not in development yet.
Closing remarks
While a large portion of modern browser development is translating specification text into code, there are still areas where specifications don’t yet cover everything that production browsers actually support.
Since Ladybird aims to render the contemporary web correctly, we have no choice but to support these features as well. Specifications will eventually catch up, and we’ll update our implementation when that happens.
Fun fact: I discovered multiple bugs in our flex layout implementation while editing this very post. They have now also been fixed!
Finally, if you like what I’m doing, please consider sponsoring me on GitHub or Patreon. I’m working on SerenityOS and Ladybird full time, thanks to the generous support of many sponsors. You can also follow me on Twitter.
Thanks for reading! Subscribe for free to receive new posts and support my work.



How we're building a browser when it's supposed to be impossible
Andreas Kling — Tue, 11 Apr 2023 06:44:38 GMT
“How is the SerenityOS team making such good progress on building their Ladybird browser, when we've heard for years that it’s impossible”?
I've seen this question a few times on sites like Hacker News and Reddit, and I thought I’d offer my own personal take on it.
From my perspective, it comes down to five main things:
Stronger web specifications
Focus on vertical slices
Deferring on performance work
Team culture
Having an experienced leader
Stronger web specifications
We’ve come a long way from the wishy-washy days of HTML4 and CSS2.1.
The ECMAScript, HTML, and CSS specifications today are (for the most part) stellar technical documents whose algorithms can be implemented with considerably less effort and guesswork than in the past.
The architecture of Ladybird tries really hard to match the architecture described in the various web specifications. This makes it significantly easier for new developers to get oriented, as they only have to learn one architecture instead of two.
There are still gaps though, and some features are less specified than others. Thankfully there’s an active community of editors at the W3C working on improvements. A fair amount of the work we do on Ladybird involves adapting our codebase to updates made by these spec editors.
We try to do our part in improving the specs as well: the Ladybird developers often report spec bugs, and sometimes make PRs to improve specs directly. Not to mention that implementing a spec in a novel browser engine provides great validation that the spec is actually complete.
Focus on vertical slices
While the specs today are indeed better than ever before, it’s still the case that many features span multiple specs, often with subtle interactions between subsystems that must be understood by an implementer.
If you tried to build a browser one spec at a time, or even one feature at a time, you’d most likely run out of steam and lose interest altogether. 
So instead of that, we tend to focus on building “vertical slices” of functionality. This means setting practical, cross-cutting goals, such as “let’s get twitter.com/awesomekling to load”, “let’s get login working on discord.com”, and other similar objectives.
Working on a vertical slice helps maintain momentum and it's highly motivating to see tangible improvement on real live websites as they progress.
This approach is in part possible because the web itself is designed around graceful degradation, meaning that browsers can render web content while only supporting some of the features used by the site.
You might think this approach would produce a small collection of “compatible websites” and a vast desert of non-working things, but what really happens is that the rising tide lifts all boats, and as we focus on improving one website, thousands of other sites improve as well!
Deferring on performance work
We're currently not putting much effort into optimizing Ladybird for performance. Instead, our primary focus is on addressing issues related to correctness and compatibility. This approach helps us stay focused on making sure the browser works as intended before diving into optimizations.
It's not that we don't care about performance. We want our browser to be fast and responsive eventually. It's a matter of making a disciplined choice to not spend too much time optimizing a product that doesn't work correctly yet. For example, while we might identify areas where we could potentially optimize JavaScript execution or rendering speed, we consciously choose to prioritize fixing rendering bugs or compatibility issues with popular websites first.
We do make exceptions for things that are unbearably slow. We don't want working on the browser to be unpleasant, after all. In such cases, we'll invest time in addressing the most significant performance bottlenecks to maintain a tolerable development experience.
But we're not tracking benchmark scores and things like that at this stage. That day will come though, once we've achieved a solid foundation in terms of correctness and compatibility!
Team culture
In the time we’ve spent together working on this, a strong team culture has formed. The culture is highly optimistic and everyone has a “can do” attitude.
Although the team is distributed around the world, we all meet on Discord to chat and spur each other on. People frequently collaborate and pitch in on each other’s projects.
Everyone who works on Ladybird is encouraged to explore their own personal interests within the project. Most folks on the team had never looked at browser code before joining us, and they're quickly becoming world-class browser developers.
Also, since Ladybird is an offshoot from the SerenityOS project, it shares the same culture of accountability and self-reliance. We avoid 3rd party dependencies and build everything ourselves. In part because it’s fun, but also because it creates total accountability for what goes into our software.
Having an experienced leader
An experienced leader can make a significant difference in a project like this. I've had the opportunity to work on production browsers for many years (at Apple and Nokia), which has given me a strong understanding of how browsers are put together.
While other people may look at the huge stack of technologies and specifications that need to be combined to make a browser and feel overwhelmed, I’ve got a clear picture of how to put them together and make it work. We save a lot of time here by not worrying about whether it’s possible and just getting straight to the work instead!
In more practical terms, what I really end up working on is often between the seams — parts of the browser that are less rigidly specified (e.g layout & rendering). Those parts can be much harder for less experienced browser developers to engage with.
Conclusion
Although I don’t believe our exact way of working is directly transferable to other software projects (unless they are also browsers), with a small team of smart, focused individuals and a knowledgeable leader to guide them, you can build any software you want.
Thanks for reading! Subscribe for free to receive new posts and support my work.



Making myself uncomfortable again
Andreas Kling — Fri, 07 Apr 2023 00:00:00 GMT
In early 2019, some months after completing a rehab program for drug addiction, I was in a very open-minded headspace where I wanted to challenge myself and find ways to improve as a person.
Drugs had filled my life with secrecy and lies, but that life was over. Although I was unsure of my next steps, I was so tired of the secrecy that I couldn’t think of anything I’d rather change about myself.
So, roughly 6 months into the SerenityOS project, I started making YouTube videos to document my progress. At the time, I was still working on the project alone, and I thought video could be an engaging format.
The first videos were simple programming sessions, filled with clumsiness and mumbling. I made lots of mistakes and mumbled even more while fixing them. Over time, I improved, and also starting making monthly SerenityOS update videos – a tradition which is still going today.
Eventually, I began recording myself driving to work, and that’s when I truly opened up. In these car videos, I discussed programming, job experiences, motivation, operating systems, and many other topics. As I grew more comfortable, I eventually shared my history with drug addiction and how it inspired the name “SerenityOS” as well. People were incredibly supportive, and for the first time since childhood I felt accepted for who I really was.
Where I am today
Just two weeks ago, I posted my 1000th video to YouTube. That’s a lot of videos. With more than 39,600 subscribers, I’ve been able to share my work, thoughts and knowledge with more people than I ever imagined.
Moreover, I’ve attracted hundreds of people to collaborate on SerenityOS with me, many of whom are still active contributors today. This experience has brought me immense joy.
At this point, I feel like I’ve accomplished my goal of becoming comfortable on camera and learned to embrace authenticity, leaving the secrecy and lies behind.
Now, I’m ready to face a new challenge and feel uncomfortable once again!
Writing: a new frontier
Writing has always intimidated me. While I can manage short bursts (like Tweets), I’ve rarely practiced writing anything more substantial. This is something I’m incredibly uncomfortable with, and I feel like it’s time to confront it.
So, here’s what I’m going to do: I’ll be taking a break from making my usual “unprepared” videos (i.e everything other than SerenityOS update videos), and focus instead on writing. I will write posts like this one, but also technical posts, book reviews, etc.
As I write this, a mix of fear and excitement fills my heart. I feel intimidated and out of my element, and this tells me I’m on the right track.
With this, I aim to become significantly better at writing. I also hope to become better at thinking. I tend to think in English, so it seems logical that improving my command of English will improve my ability to think as well.
To follow along on my new journey, stay tuned for regular blog updates and post announcements on my Twitter.
It’s going to be bumpy at first, but I’ll do my best to improve quickly.
Thank you for reading! I hope to see you here again.


MutexProtected: A C++ Pattern for Easier Concurrency
Andreas Kling — Thu, 06 Apr 2023 00:00:00 GMT
In this post, we will discuss the challenges of programming with locks and how the C++ language offers some useful tools to make it easier. We will start with an example in C and then use C++ to improve upon it in steps. The example APIs are based on real-life APIs from the SerenityOS kernel.
Barebones example in C
Let’s imagine a struct Thing with a field field that will be accessed by multiple threads. We’ll use a mutex mutex to ensure that only one thread can access it at a time.
struct Thing {
    Mutex mutex;
    Field field;
};
In C, accessing Thing would typically look something like this:
mutex_lock(&thing->mutex);
use(&thing->field);
mutex_unlock(&thing->mutex);
An obvious problem in the C version is that the mutex must be manually unlocked. Forgetting to unlock a mutex tends to have unpleasant consequences.
Improving it with a C++ RAII class
The “forgot to unlock” problem is easily solved in C++ with a RAII class for automatic locking & unlocking:
{
    MutexLocker locker(thing->mutex);
    use(thing->field);
}
The MutexLocker locks the mutex when constructed and unlocks it when destroyed. No need for a manual call to mutex_unlock() anymore.
That’s already pretty good! However, the MutexLocker approach still has some major shortcomings:
You can still forget to lock the mutex and access field anyway.
Developers who are unfamiliar with this code may not realize that mutex and field have this important relationship.
Even so, the MutexLocker was our favored pattern in SerenityOS up until 2021, when we introduced a new pattern to the codebase.
Adding lambdas to the mix: introducing MutexProtected
MutexProtected is a powerful C++ construct that addresses the main issues with MutexLocker and makes it significantly easier to use mutexes correctly:
struct Thing {
    MutexProtected field;
};

thing->field.with([&](Field& field) {
    use(field);
});
Essentially, MutexProtected is a bundled mutex and T. However, you can’t access the T directly! The only way we’ll let you access the T is by calling with() and passing it a callback that takes a T& parameter.
When called, with() locks the mutex, then invokes the callback, and finally unlocks the mutex again before returning.
As you can see, we’ve now also solved the issue of someone forgetting to lock the mutex before accessing the field. And not only that, but since the mutex and field have been combined into a single variable, you no longer have to be aware of the relationship between the two. It’s been encoded into the type system!
When multiple fields are protected by a single mutex, we can simply combine them into a struct:
struct ManyFields {
    Field1 field1;
    Field2 field2;
    Field3 field3;
};

struct Thing {
    MutexProtected fields;
};
Note that it’s still possible to make mistakes with MutexProtected, such as deadlocking the program by using multiple MutexProtected simultaneously in inconsistent order. Thankfully such bugs are generally trivial to diagnose compared to data races.
That concludes our look at MutexProtected. If you’re currently working on a C++ project using mainly the MutexLocker approach, consider adding something like our MutexProtected to further reduce the chances of using locks incorrectly.
You can find the SerenityOS implementation on GitHub. (Note that it’s a little more sophisticated than the imaginary MutexProtected I’ve used for examples above.)
Final notes
Although MutexProtected was introduced to SerenityOS in 2021, we do still have a lot of code using the old MutexLocker pattern. There are still cases where MutexLocker works better, for example when a mutex is used to synchronize something other than data.
And yes, it is possible to make life difficult by persisting the T& to an outside location while inside the callback. This is C++ after all, so the programmer does have great freedom. However, doing so is definitely not recommended, and we have yet to encounter anyone trying to do this in our codebase.


Excellence is a habit, but so is failure
Andreas Kling — Wed, 05 Apr 2023 00:00:00 GMT
We often hear that making small incremental improvements every day can lead to great things. This popular piece of advice rings true, and it’s a powerful reminder to keep pushing ourselves forward.
But there’s another side to this story that we don’t discuss as often: how incremental neglect and small missteps can accumulate and lead to negative outcomes. Recognizing and addressing these patterns of neglect early can make a significant difference in preventing larger problems down the road.
Reflecting on my own life, I’ve noticed that most of the things that really went off-track were indeed consequences of incremental neglect and numerous small yet poor choices:
I didn’t become addicted to drugs overnight. It happened over hundreds of moments where I prioritized momentary pleasure over health and safety.
I didn’t become overweight overnight. It happened over hundreds of moments where I opted for immediate gratification over long-term health.
I didn’t ruin relationships overnight. It happened over hundreds of moments where I chose comfort over confronting difficult conversations, admitting my mistakes, or even just acknowledging that someone was better than me at something.
From these experiences, I’ve realized that avoiding bad habits is just as important as cultivating good habits.
To address these kinds of issues, we must become aware of our patterns of incremental neglect and then take deliberate steps to counteract them and foster healthier habits.


How SerenityOS declares ssize_t
Andreas Kling — Tue, 04 Apr 2023 00:00:00 GMT
This post explores one of my favorite hacks in SerenityOS. I don’t recommend doing this in your codebase, but it has worked for us so far. :^)
Background
size_t and ssize_t are common types used in many POSIX APIs. According to POSIX, they are used as follows:
size_t: Used for sizes of objects.
ssize_t: Used for a count of bytes or an error indication.
In practice, ssize_t is essentially a “signed size_t”.
Since we’re building the whole operating system, including the standard C library ourselves, we’re also responsible for declaring all the common system types, including size_t and ssize_t.
How we declare them
To declare size_t, we leverage the C preprocessor’s predefined __SIZE_TYPE__ macro:
typedef __SIZE_TYPE__ size_t;
However, there is no __SSIZE_TYPE__ macro for ssize_t, so I decided to get a little creative:
#define unsigned signed
typedef __SIZE_TYPE__ ssize_t;
#undef unsigned
Here’s what’s happening: The C preprocessor expands “__SIZE_TYPE__” to “unsigned long” or something similar. We trick it by temporarily defining a macro that replaces “unsigned” with “signed”, and so ssize_t is declared as a signed version of whatever the size_t type is!
How others declare them
Other C libraries typically use more careful techniques, such as wrapping the declarations in architecture-specific #ifdefs:
#ifdef __i386__
typedef uint32_t size_t;
typedef int32_t ssize_t;
#endif

#ifdef __x86_64__
typedef uint64_t size_t;
typedef int64_t ssize_t;
#endif
That’s obviously a better approach if you’re building with compilers that don’t predefine __SIZE_TYPE__, or in an environment where unsigned has already been redefined.
In our case, we haven’t had any issues with our approach yet, so I’m inclined to hold on to the hack as it’s just so cute. :^)


15 Minutes Every Day
Andreas Kling — Mon, 03 Apr 2023 00:00:00 GMT
Someone once suggested that I set aside a small portion of my income every month. I’ve been doing this for years with an automatic bank transfer so I can’t mess it up.
I was reflecting on this habit recently, and had a thought: what if I treated cleaning the same way?
I’ve never been good at cleaning. Every place I ever lived was a bit messy, except when expecting a visitor.
The idea became: every day I’d “invest” 15 minutes into our home by picking a small cleaning task and doing it immediately after breakfast. I shared the idea with my wife, and we agreed to test it out together.
For the first few days, we found things to do easily, such as organizing cables, tools, pantry items and clothes. Then, we moved on to cleaning tasks, like scrubbing cabinets, washing floors, and cleaning the sofa.
These kind of things used to be so hard for me to get done, but now I’m doing them every day, and it’s even fun doing them together with my wife. We also do a little “demo” when we’re finished, to show each other what we accomplished.
We’re only 2 weeks into this, and our home looks noticeably nicer. I also find it easier to keep it nice, since any small mess now stands out way more than it did before.
I’m sure there’s a novelty aspect to why I’m enjoying this, but even so, it really does feel like a sustainable habit, especially since it’s only 15 minutes every day.


How I make a living working on SerenityOS
Andreas Kling — Sat, 29 Oct 2022 00:00:00 GMT
This post describes in detail how I support myself while working on the SerenityOS project.
Introduction
Hello! My name is Andreas Kling and I’m the founder of the SerenityOS project. If you’re not familiar, SerenityOS is a from-scratch operating system that I started building in 2018. It combines a Unix-like core with the look & feel of the late 1990s. Although it began as a one-man project, it has since blossomed into a lively open source community with hundreds of amazing developers working on it.
Since May of 2021, SerenityOS has been my full-time job. This terrifying but exciting leap was made possible by recurring donations from generous people who like what I do and want to see it continue.
With so many people having my back, I’ve grown a bit more courageous with taking on large projects, which has led to SerenityOS expanding into both a new memory-safe systems language (Jakt) and a new cross-platform browser (Ladybird) in the last year.
“Okay, but how do you actually make a living?”
I get this question regularly, so I’m going to do my best to answer it. Please understand that I’m publishing this for transparency, not to brag about making so much or complain about not making enough.
All currency amounts below are in USD.
Main source of income: Individual sponsorships/donations
I created a Patreon back in April of 2019. I felt a bit silly at the time, with thoughts like “who do I think I am” and “what am I even doing” echoing in my head. I still did it though. I was too curious to see what would happen, even though I expected nothing. Amazingly, a couple of people actually signed up!
Later on, when GitHub Sponsors opened up, I got in as early as I could. Not only did they have zero fees, but they also offered to match the first $5,000 in donations. And once again, some people actually signed up!
On both platforms, people are invited to donate to me personally so that I can spend time working on SerenityOS. No goods/services are offered in return.
Here are the current numbers as of 2022-10-29. They tend to fluctuate as people join and leave as supporters.
Platform Supporters $/month GitHub Sponsors 263 2,136 Patreon 268 1,411 PayPal <5 <200 Cryptocurrency <5 <50
Early on I would monitor these numbers closely, as I found it fascinating. Eventually it became a source of stress, so now I only check on them once a month when I do my accounting.
Secondary source of income: YouTube
I’ve been fairly active on YouTube since early on in the SerenityOS project. I started uploading development videos about ~6 months into the project. They were awkward and clumsy, but people seemed to enjoy watching someone incrementally building a new operating system from scratch.
Once the channel grew large enough, I was able to enable monetization in the form of ads. I felt a bit weird about this, since I use an ad blocker myself, but I figured that the kind of person who watches my content is perfectly aware of ad blockers and can make their own decisions about them.
Income from ads varies wildly depending on how often I upload new videos, and how many views they get. YouTube’s terms & conditions don’t allow me to disclose analytics in detail, but my estimated revenue this month is $315.
Outside of ads, I also have 58 people enrolled as “channel members”, which nets $65/month (part of the $315). YouTube allows you to create separate content for channel members, but I don’t make use of this feature as I prefer that everyone has access to everything I make. The one thing that channel members do get is the ability to use our fancy SerenityOS and yak-shaving-themed emotes when commenting/chatting the channel.
Finally, YouTube also allows people to send “super chats” during live streams. These are irregular, but this month I have received $50 across 8 super chats (also part of the $315).
Tertiary source of income: Merch
People kept asking me for SerenityOS related merch like t-shirts and tea cups, so I ended up making a print-on-demand store using Teespring. Afterwards, people have told me that they felt much more comfortable supporting the project if they got something in return, “like a laptop sticker or something”. This makes perfect sense, but had not occurred to me before.
Monthly income from merch varies greatly. Last month it was $0 and so far this month it’s at $101. People are not going to buy the same t-shirt over and over again, so you have to put in some effort into making new designs/products available.
Non-income: Sponsored/native advertising
I’ve been approached to advertise a number of products, including (but not limited to) mobile games, VPN services, programming courses, zero-day exploit brokers, cloud platforms, etc.
So far I haven’t accepted any of these offers, as I made a rule for myself that I wouldn’t advertise something I’m not personally using.
The only thing that came somewhat close was when I started using the CLion IDE, the folks at JetBrains gave me three 1-year license codes to raffle out to my YouTube audience. Since I use CLion daily, both on and off YouTube, I would be happy to partner with them, but so far we’re just friends. :^)
Non-income: Venture capital
I’ve also been approached by a handful of folks from VC firms and while I have nothing against them, I’m not taking any meetings. I’m not interested in selling influence over the things I work on, and I’d much rather have many small donors who believe in me than one huge investor telling me what to do.
Accounting and taxes
All of the above is a fairly unusual way of making a living, so there isn’t a lot of guidance from Swedish tax authorities on how to report things, etc. I wanted to make sure that everything is done correctly, and that I pay all the taxes I’m supposed to, so I ended up hiring an accounting consultant.
They advised me to start a business, since it would make accounting much more straightforward, so in 2021 I formed Cerphus Software AB. The name comes from the imaginary software company I had as a child. :^)
I was trying to come up with a nice name for my business, and while there were many good options, I decided to fulfill a childhood dream and turn my then-imaginary "software company" into a real one.

I've just signed the documents forming Cerphus Software AB 👦💻🦌 https://t.co/LK2lPfSw7Z
— Andreas Kling (@awesomekling) June 28, 2021
I’m extremely glad that I hired an accountant. It cost a bit of money to get everything up and running, but we’ve settled into a comfortable routine, and they only need to spend a little bit of time per month on filing everything for me.
In fact, other than the occasional computer part, accounting services is the only real expense I have.
Summary & closing thoughts
As you can see, the numbers above put me at roughly $4200 this month. My wife and I live a modest life, and while taxes in Sweden are high, this is enough to break even where we are right now.
I know I could make a lot more money doing something else, but having the freedom to work on SerenityOS (and Jakt and Ladybird) in peace is worth infinitely more.
It’s incredibly humbling to have so many people support me financially so that I can continue my work. My massive heartfelt thanks to everyone who has supported me in the past and present! ❤️
In the future, I would love to be able to pay more people to work on the project. Especially now that we’re making a truly independent open source cross-platform web browser, I think there’s a lot of room to grow. I don’t know exactly how to do this yet, but when/if there’s enough support, I will find a way to restructure so I can hire people.
My Links
YouTube | Patreon | GitHub Sponsors | PayPal | Teespring | Ethereum


Ladybird: A new cross-platform browser project
Andreas Kling — Mon, 12 Sep 2022 00:00:00 GMT
This post describes the Ladybird browser, based on the LibWeb and LibJS engines from SerenityOS.
Since starting the SerenityOS project in 2018, my goal has been “to build a complete desktop operating system to eventually use as my daily driver”.
What started as a little therapy project for myself has blossomed into a huge OSS community with hundreds of people working on it all over the world. We’ve gone from nothing to a capable system with its own browser stack in the last 4 years.
Throughout this incredible expansion, my own goals have remained the same. Today I’m updating them a little bit: in addition to building a new OS for myself, I’m also going to build a cross-platform web browser.
A browser is born
The Ladybird browser came to life on July 4th, when I recorded a video of myself making a simple Qt GUI for the LibWeb browser engine. Thanks to some recent work by Dex and others, we had LibWeb building on Linux in headless mode, so I decided to push ahead and build a simple GUI around it.
I originally imagined Ladybird as a debugging tool that made it easier for people to remain in Linux while working on LibWeb if they wanted to. It’s now two months later, and I find myself using Ladybird for most of my own browser development work.
At this point, we might as well tweak the scope from “browser engine for SerenityOS” to “cross-platform browser engine” and build something that many more people could potentially have use for some day. :^)
Note that LibWeb started back in 2019, then called LibHTML:
commit a67e823838943b31fb7cea68bd592093e197cf16
Author: Andreas Kling
Date:   Sat Jun 15 18:55:47 2019 +0200

    LibHTML: Start working on a simple HTML library.
LibJS began almost 9 months later, in 2020:
commit f5476be702009968468731df5e23cdeb68fdb6e0
Author: Andreas Kling
Date:   Sat Mar 7 19:42:11 2020 +0100

    LibJS: Start building a JavaScript engine for SerenityOS :^)
If you’re interested, you can see exactly how I started the LibJS engine, as the whole process was recorded for YouTube :^)
Basic architecture
Both LibWeb and LibJS are novel engines. I have a personal history with the Qt and WebKit projects, so there’s some inspiration from them throughout, but all the code is new. Not to mention, hundreds of people have worked on the codebase since I started it, all adding their own personal influences, so it’s definitely its own thing.
The browser and libraries are all written in C++. (While our own memory-safe Jakt language is in heavy development, it’s not yet ready for use in Ladybird.)
Here’s a rough breakdown of the current stack:
Ladybird: Tabbed browser GUI application
LibWeb: Web engine, multiple standards: HTML, DOM, CSS, SVG, …
LibJS: The ECMAScript language, runtime library, garbage collector
LibGfx: 2D graphics, text rendering, image formats (PNG, JPG, GIF, …)
LibRegex: Regular expression engine
LibXML: XML parser
LibWasm: WebAssembly parser and interpreter
LibUnicode: Unicode support library
LibTextCodec: Text encoding conversion library
LibMarkdown: Markdown parser
LibCore: Miscellaneous support functions (I/O, datetime, MIME data, …)
Qt: Cross-platform GUI and networking
LibWeb has a Platform layer where Ladybird injects Qt support code for event loops, timers, system font settings, etc. We currently use Qt for networking in Ladybird, as the multi-process RequestServer system is not available outside of SerenityOS yet. Likewise, Ladybird is currently single-process, while the SerenityOS browser is process-per-tab. All of this is temporary and will change over time.
License & “business model”
Ladybird and its engine are freely available under the 2-clause BSD license. You cannot buy influence over the project, but you can improve the browser by participating in development!
I’m personally working on these projects full time since 2021 thanks to my generous supporters. If you like what I’m doing, you can help me do more of it by supporting me on GitHub Sponsors, Patreon or PayPal.
I would love to have enough money to pay others to work on Ladybird some day. At the moment, I make just enough to support my own family, but if things should grow past the point where I’m comfortable, I will look into restructuring so I can hire more help.
In addition to myself, you can already directly sponsor Linus Groh and Sam Atkins who both do a lot of excellent browser work.
A note on maturity
Please note that we’re still early in development, and many web platform features are missing or broken. It’s going to take a long time before Ladybird is ready for day-to-day browsing.
We’re very much in the “make it work” part of the “make it work, make it good, make it faster” cycle. As such, we tend to focus a lot more on correctness and feature support rather than optimization. Performance work happens mostly at the architectural level, although targeted optimizations that relieve particular pain points do also happen.
Please note that this is not a product announcement or release, but more of a personal announcement that I’m adding “a truly independent cross-platform browser” to my list of personal goals. It’s also an invitation to anyone who might be interested in working on a completely new browser. :^)
As you can see above, we do pass the classic Acid3 standards test, which covers a bunch of basic CSS layout features, and various DOM/HTML APIs. However, the test does not cover many of the features used on the web today (like CSS flexbox, CSS grid, etc.)
Fidelity of modern websites in Ladybird is steadily improving, but you’ll often see lots of layout and compatibility issues. For example, here’s Reddit right now:
Community acknowledgment
Sometimes people write articles saying I’m “single-handedly” doing this or that. I’m not! Both Ladybird and SerenityOS are community efforts that hundreds of awesome people are pouring their heart and soul into. I write a lot of code, and I do my best to cheerlead for the community, but I absolutely wouldn’t be here without them!
FAQ
Q: Which platforms will Ladybird support?
So far, we’ve seen it running on Linux, macOS, Windows (WSL) and Android. The Linux version is definitely the most tested.
Since the libraries come from SerenityOS, they’re already self-contained, and we only need Qt to help us with GUI and networking. This makes the browser quite portable, and in theory we could run wherever Qt runs. In practice, we’ll see what happens.
Q: When will Ladybird be ready for use?
I don’t know. It depends on what you consider “ready”, but I’d expect a few more years of development before we have something solid. You can accelerate this process by participating in development and/or supporting our developers financially.
Q: How can I participate in development?
The most important work ahead of us is fixing bugs and adding missing features to LibWeb and LibJS. If you try opening your favorite website in Ladybird, you will find bugs! To participate in development, figure out the bug and fix it. Development discussion primarily happens in the #browser and #js channels on our Discord server, so come join us there.
Q: I found a website that does not work! Where do I report this?
At this point, there are way more websites that don’t work than websites that do. We’re not yet at the point where reporting individual site issues makes sense.
That said, if you’re going to actually work on fixing the problems, feel free to track them using GitHub issues if that helps you.
Q: Do you have a JavaScript JIT compiler?
No, we have a traditional AST interpreter that is being replaced by a bytecode VM. You can track the LibJS test262 score for both backends here. I’m not convinced that the complexity and security burdens of a JavaScript JIT are reasonable, and given recent developments like Microsoft Edge’s Super Duper Secure Mode, I’m interested in pushing for best-effort JIT-less performance while keeping the codebase simple.
Q: I opened Acid3 in my browser and I only got 97/100. What’s wrong?
You’re using an older version of the test that does not reflect settled web standards. The up-to-date version is here: http://wpt.live/acid/acid3/test.html.
Q: Why bother? You can’t make a new browser engine without billions of dollars and hundreds of staff.
Sure you can. Don’t listen to armchair defeatists who never worked on a browser.
Contact
If you’re interested in working on Ladybird, LibWeb, LibJS, or any part of the supporting stack, you can find us on the SerenityOS Discord. :^)


Memory safety for SerenityOS
Andreas Kling — Thu, 19 May 2022 00:00:00 GMT
This post describes how we’re going to achieve memory safety in SerenityOS.
After visiting my nephews for easter, I spent the drive back home thinking about the future they will grow up in. What will their computers look like? What kind of software will they use? Will any of my code still be running?
When I started the SerenityOS project in 2018, I used C++ for everything, simply because it was the language I was most comfortable with. It was the right choice at the time, as it allowed me to bootstrap the project (and a community) very quickly and efficiently.
In the time since then, SerenityOS has grown larger and more complex, and we recently passed 700 individual contributors! It’s far from a one-man hobby project at this point.
When thinking about the future, I would love for SerenityOS to be around in 30 years, when my nephews are my age (and I’m an old greybeard!)
While I believe our community and system architectures are strong enough to sustain development for years to come, I no longer believe that C++ is the right language for us.
As much as I enjoy using it, the lack of memory safety in C++ means that we’ll always have bugs that could have been avoided. I’m tired of this, and I don’t want to spend the next decades of my life debugging more avoidable bugs.
To improve the longevity of SerenityOS, we need to make the system memory-safe.
So how do we achieve memory safety?
I spent a few weeks exploring the current landscape of memory-safe systems languages. I learned a handful of new ones so I could see how they work, and understand what they do to achieve safety.
I tried rewriting parts of SerenityOS in different languages, and while there were some interesting options, they all came with idiosyncratic limitations and dependencies that made them unsuitable for adoption.
Since the beginning, SerenityOS has been about making everything ourselves, for fun, for love of programming, for control, for performance, for vertical integration, etc.
In fact, the main thing we haven’t made ourselves is a programming language.
Yak-baiting a friend
Throughout this process, I’d been talking to my friend JT and sharing the struggle I had with the various languages. After talking their ear off about why some language wasn’t a good fit, I got this intriguing message:
NOTE: "yakbait" is SerenityOS slang for baiting someone into shaving your yak
JT went on to suggest that instead of settling for an existing language, we could design a new language by simply stealing the stuff we liked from other languages, and skipping the stuff we didn’t like or need.
To simplify incremental adoption, the new language would transpile to C++, which could then easily interact with our existing code.
I was hooked. Transpiling to C++!? I didn’t even realize that was an option!
We decided to name it Jakt (Swedish for “hunt”). What followed was 2 weeks of intense compiler bootstrapping with JT.
The language is now at a point where I feel comfortable telling you that we’re working on it, but it’s still a long way from “ready”.
Jakt
So, let’s take a look at Jakt! It’s…
Object-oriented
Safe by default
Paranoid about integer overflow & truncation
Immutable by default
Young and immature, not ready for anything serious
The current Jakt compiler is written in Rust and spits out C++. Development happens in the jakt repository on GitHub.
A little Jakt program
class Language {
    name: String
    age_in_days: i64
    
    function greet(this) {
        println("Hello from {}!", this.name)
        println("I am this many days old:")
        for i in 0..this.age_in_days {
            println(":^)")
        }
    }
}

function main() {
    let jakt = Language(name: "Jakt", age_in_days: 14)
    jakt.greet()
}
Memory safety
So how does Jakt achieve memory safety? Through a combination of these techniques:
Automatic reference counting of all class instances.
Runtime bounds checking of arrays and slices.
No dereferencing raw pointers in safe (default) code. unsafe keyword for situations where it’s necessary.
weak references that get emptied on pointee destruction.
Roadmap
Here’s a very fluffy 10 year roadmap for this project:
Bring up basic language features.
Improve static analysis in the compiler.
Write an auto-formatter for Jakt.
Rewrite the Jakt compiler in Jakt.
Integrate Jakt with the SerenityOS build system.
Incrementally rewrite SerenityOS in Jakt.
Stop transpiling to C++ and generate native code directly.
FAQ
Q: Why not just use an existing language?
I have nothing bad to say about other languages. This is simply the option that makes the most sense for SerenityOS, which is fundamentally about having fun and implementing everything ourselves.
Q: Why does Jakt have flaws?
It’s two weeks old.
Q: When will Jakt be done? Will it hit 1.0?
It will evolve with SerenityOS, so as SerenityOS matures no doubt Jakt will as well.
Q: Why ARC (automatic reference counting) instead of a borrow checker?
ARC allows the language to feel lightweight without constantly asking the user to make decisions about memory management.
There’s a little bit of overhead from maintaining reference counts, but we’re betting that the comfort gained will outweigh the cost.
Q: What about iterator invalidation?
We’re discussing a number of approaches, but have not settled on one yet.
Q: What about thread safety?
Jakt currently does nothing to enforce thread safety. We have not started looking at this area yet.
Contact
If you’re interested in working on Jakt, you can find us on the SerenityOS Discord. :^)


I quit my job to focus on SerenityOS full time
Andreas Kling — Fri, 28 May 2021 00:00:00 GMT
Hello friends! :^) Let me tell you a story…
It was October 2018 and I had just completed a 3-month rehab program at a state addiction clinic in Sweden. I was unemployed, staying with family, and had basically nothing going on.
With no drugs or other vices to pass the time, the days seemed impossibly long. I struggled to find activities to fill them. I enrolled in school for a while, but it wasn’t for me this time either. Eventually I turned to programming, since it’s always been my big interest in life.
Until that point, my career had been focused on web browsers (WebKit at Apple & Nokia). However, I had always been interested in low-level things so I began tinkering with some of that. I wrote a little ELF executable parser.. And an Ext2 filesystem browser.. And a little GUI framework with an event loop..
Out of this tinkering, an operating system began to take shape. I chose the name SerenityOS because I wanted to always remember the Serenity Prayer. I was quite worried about my future at the time, and I figured that this name would help me stay on the good path.
My general idea was to build my own dream system for daily use. It would be a combination of my two favorite computing paradigms: the 1990s GUI and the no-nonsense command-line of late-2000s Unix.
While at Apple, I really enjoyed how most of the software was made under one roof. Not only did this enable super tight integrations, but it made the system extremely hackable for its developers, and you could always find the experts somewhere nearby. I thought I could try bringing that same feeling to the open source world, so I decided that SerenityOS wasn’t going to be a patchwork of packages – no, we’re building everything ourselves! From kernel to web browser, and everything in between.
So I started hacking, day after day. Week after week. Month after month. The project became my rock as I slowly learned to navigate life again.
I decided to record some of my programming sessions and posted them to my YouTube channel. I was very uncomfortable with this at first, but I kept at it since I liked the feeling of just being myself and letting people see me, instead of putting on a mask and pretending everything was fine.
Over time, more people discovered my little project (and my little channel), and many found something that really resonated with them. Since those humble beginnings, it has grown into a vibrant open source community with hundreds of contributors from all over the world. To say that this has been an amazing journey would be an understatement, yet in many ways we are still only getting started.
Until now, I’ve been juggling SerenityOS as a side project while also having a full time programming job.
That all changes today! I just wrapped up my last day at work, and I’m no longer employed. Instead, I will be focusing on SerenityOS full time starting right now! :^)
This is all made possible by the extremely generous support I’m receiving from folks via Patreon, GitHub Sponsors and PayPal! I feel super fortunate to have the trust & support of so many people. Thank you all so much!!
At the time of writing, I’m receiving a bit over $2000 in donations per month. There’s also a modest amount from YouTube (say $150/month), as well as sales of SerenityOS merchandise (another $100).
This isn’t yet enough to fully sustain me and my family, but it’s close enough that I decided it’s time to take a chance and see what happens!
As you probably understand, I’m not trying to get rich by doing this. I’m just a human being trying to stay sane and healthy, and it just so happens that my therapy/self-care project resonates with thousands of people, many of whom want to support it and see where it goes.
It’s truly an honor to find myself in this position, and I promise that I will continue doing my best. Thank you so much for reading this post. I’m gonna have a nap and then we’ll start fresh in the morning! :^)
Andreas Kling



Smarter C/C++ inlining with __attribute__((flatten))
Andreas Kling — Mon, 27 Apr 2020 00:00:00 GMT
This post describes a compile-time technique for getting the benefits of aggressive inlining in hot code while protecting cool code from its downsides.
Hello friends!
A common technique for improving performance of hot code in C/C++ is to inline the hottest functions called. While it often helps make things faster, there are some downsides to inlining. Let’s quickly review the pros & cons:
Pros of inlining:
Removes function call overhead (yay!)
May reveal additional optimization opportunities (sometimes yay!)
Cons of inlining:
Increases program size (boo!)
May reduce cache locality (sometimes boo!)
May increase build times (boo!)
When compiling with optimizations, the compiler usually makes pretty reasonable choices about which functions to inline. It uses a combination of heuristics, with function size being the most important one AFAIK.
Manual inlining with __attribute__((always_inline))
However, sometimes you know some code is hot and the compiler has no idea. This is usually when __attribute__((always_inline)) comes in. If you add this attribute to a function, that function will now be inlined wherever it is called, even when the compiler would normally have dismissed it as too large. (Note that there are exceptions to this, and some functions cannot be inlined.)
Here’s a contrived example of a very common scenario in larger codebases:
__attribute__((always_inline)) inline void do_thing(int input)
{
    // this code is always inlined at the call site
}

void hot_code()
{
    // the program spends >80% of its runtime in this function
    while (condition) {
        ...
        do_thing(y);
        ...
    }
}
The above is all well and good, but what happens when do_thing() is a popular function that gets called a lot?
void cool_code()
{
    // the program spends <5% of its runtime in this function
    ...
    do_thing(a);
    do_thing(b);
    do_thing(c);
}
Now the cool_code() function gets three copies of do_thing() inlined into it, invoking all of the cons from the list we made above (larger program size, worse cache locality, longer build time.)
Targeted flattening instead of global inlining
Now for the trick! Both GCC and Clang support __attribute__((flatten)). Putting it on a function causes all of its callees to be inlined into it. It’s dead simple.
void do_thing(int input)
{
    // this code is not always inlined at the call site
}

__attribute__((flatten)) void hot_code()
{
    // the program spends >80% of its runtime in this function
    while (condition) {
        call_something();   // inlined!
        do_thing(y);        // inlined!
        other_thing();      // also inlined!
    }
}

void cool_code()
{
    // the program spends <5% of its runtime in this function
    ...
    do_thing(a);            // not inlined!
    do_thing(b);            // not inlined!
    do_thing(c);            // guess!
}
Note: Functions with __attribute__((noinline)) will not be inlined. The same goes for functions where the compiler can’t see the body.
In conclusion
__attribute__((flatten)) lets you opt in to the pros of aggressive inlining on a per-function basis, while protecting the rest of your program from the cons!
Until next time! :^)

Andreas Kling

I'm forking Ladybird and stepping down as SerenityOS BDFL

Two projects in one space

What does this mean for Ladybird?

What does this mean for SerenityOS?

Fuzzing Ladybird with tools from Google Project Zero

Issue #1: inside

Issue #2: Assigning window event handlers in detached DOM

Issue #3: Infinite recursion in SVG

Issue #4: Accessing the window properties of a removed iframe

Issue #5: Infinite looping in Element.before()

Conclusion

Welcoming Shopify as a Ladybird sponsor

15-minute habit: Magyarul tanulok! (I am learning Hungarian)

Running Ladybird with foreign GUI toolkits

Born in the fires of SerenityOS

Attempt 1: abstraction at the wrong layer

Attempt 2: abstraction at the right layer

What’s so great about this?

Resizing the Mac App Store: a tale of regret & redemption

Investigating the issue

My optimizations

An optimization that didn’t work out

It got better, but still too laggy

Rescued by Dave Hyatt

From regret to redemption

Implementing an underspecified CSS feature (flexbox gaps)

History of gaps in CSS

Okay, let’s read the spec...

Implementing it in Ladybird

Before & After

When will flexbox gaps be properly specified?

Closing remarks

How we're building a browser when it's supposed to be impossible

Stronger web specifications

Focus on vertical slices

Deferring on performance work

Team culture

Having an experienced leader

Conclusion

Making myself uncomfortable again

Where I am today

Writing: a new frontier

MutexProtected: A C++ Pattern for Easier Concurrency

Barebones example in C

Improving it with a C++ RAII class

Adding lambdas to the mix: introducing MutexProtected

Final notes

Excellence is a habit, but so is failure

How SerenityOS declares ssize_t

Background

How we declare them

How others declare them

15 Minutes Every Day

How I make a living working on SerenityOS

Introduction

“Okay, but how do you actually make a living?”

Main source of income: Individual sponsorships/donations

Secondary source of income: YouTube

Tertiary source of income: Merch

Non-income: Sponsored/native advertising

Non-income: Venture capital

Accounting and taxes

Summary & closing thoughts

My Links

Ladybird: A new cross-platform browser project

A browser is born

Basic architecture

License & “business model”

A note on maturity

Community acknowledgment

FAQ

Q: Which platforms will Ladybird support?

Q: When will Ladybird be ready for use?

Q: How can I participate in development?

Q: I found a website that does not work! Where do I report this?

Q: Do you have a JavaScript JIT compiler?

Q: I opened Acid3 in my browser and I only got 97/100. What’s wrong?

Q: Why bother? You can’t make a new browser engine without billions of dollars and hundreds of staff.

Contact

Adding lambdas to the mix: introducing `MutexProtected`

Smarter C/C++ inlining with attribute((flatten))

Manual inlining with `attribute((always_inline))`