Problem: A document could drop a load if it ran a stream of synchronous
same-document history navigations (say, a pushState flood) while it was
concurrently loaded again. The load never finished — so on sanitizer/
slow builds, this had been intermittently taking down unrelated tests in
CI — since test-web reuses one WebContent process, and the next test’s
load can arrive while the previous document’s history work is still
draining. A synchronous commit also claimed a session history step it
never retired — so claimed steps piled up without bound.
Cause: A sync same-document navigation committed immediately and could
jump the session-history-traversal queue while a queued apply-history-
step — such as a cross-document load — was still waiting behind it. The
queued run read the active session-history entry after the sync
navigation had installed it, but before its step number was assigned —
then judged itself stale against that still-pending step, and was
discarded. The shared step numbering was fragile under the same nesting:
A number computed from the current step alone could collide with an in-
flight one — and a stale run that completed later could write its own
step back over a newer one.
|
||
|---|---|---|
| .devcontainer | ||
| .github | ||
| AK | ||
| Base/res | ||
| Documentation | ||
| Libraries | ||
| Meta | ||
| Services | ||
| Tests | ||
| UI | ||
| Utilities | ||
| .clang-format | ||
| .clang-tidy | ||
| .clangd | ||
| .editorconfig | ||
| .gdbinit | ||
| .gitattributes | ||
| .gitignore | ||
| .lldbinit | ||
| .mailmap | ||
| .pre-commit-config.yaml | ||
| .prettierignore | ||
| .prettierrc | ||
| .ycm_extra_conf.py | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CMakeLists.txt | ||
| CMakePresets.json | ||
| CODE_OF_CONDUCT.md | ||
| CONTRIBUTING.md | ||
| ISSUES.md | ||
| LICENSE | ||
| pyproject.toml | ||
| README.md | ||
| rust-toolchain.toml | ||
| rustfmt.toml | ||
| SECURITY.md | ||
| vcpkg-configuration.json | ||
| vcpkg.json | ||
Ladybird
Ladybird is a truly independent web browser, using a novel engine based on web standards.
Important
Ladybird is in a pre-alpha state, and only suitable for use by developers
Features
We aim to build a complete, usable browser for the modern web.
Ladybird uses a multi-process architecture with a main UI process, several WebContent renderer processes, an ImageDecoder process, and a RequestServer process.
Image decoding and network connections are done out of process to be more robust against malicious content. Each tab has its own renderer process, which is sandboxed from the rest of the system.
At the moment, many core library support components are inherited from SerenityOS:
- LibWeb: Web rendering engine
- LibJS: JavaScript engine
- LibWasm: WebAssembly implementation
- LibCrypto/LibTLS: Cryptography primitives and Transport Layer Security
- LibHTTP: HTTP/1.1 client
- LibGfx: 2D Graphics Library, Image Decoding and Rendering
- LibUnicode: Unicode and locale support
- LibMedia: Audio and video playback
- LibCore: Event loop, OS abstraction layer
- LibIPC: Inter-process communication
How do I build and run this?
See build instructions for information on how to build Ladybird.
Ladybird runs on Linux, macOS, Windows (with WSL2), and many other *Nixes.
How do I read the documentation?
Code-related documentation can be found in the documentation folder.
Get in touch and participate!
Join our Discord server to participate in issue and development discussions.
Please read Getting involved with Ladybird if you're new to Ladybird and want to help.
Before opening an issue, please see the issue policy and the detailed issue-reporting guidelines.
The project participation guidelines can be found in CONTRIBUTING.md.
License
Ladybird is licensed under a 2-clause BSD license.