repository·master·Indexed 13 days ago
https://github.com/ladybirdbrowser/ladybirdAn independent web browser built from scratch using a novel engine based on web standards. Currently in pre-alpha for developer use, the project includes documentation on its general architecture, LibWeb components, build instructions for Linux, macOS, and Windows, and specialized tools for randomized testing and fuzzing.
The project follows a multi-year roadmap toward a stable release:
The Omnibox popup renders an ordered suggestion list with the following visual characteristics:
LibWebView. Highlighting uses both weight and brightness to ensure visibility in both dark and light themes.Ladybird follows specific coding patterns to ensure fidelity to web standards:
"AD-HOC:" comment prefix to mark code that does not map to any specific specification requirements.Navigable.h, Transferable.h).Ladybird is written primarily in C++ and uses the internal AK library instead of the standard C++ STL.
Because many AK and internal library facilities are not extensively documented, you should learn by:
Key Developer Documentation:
Automatic selection and inline completion are separate decisions. A result can be displayed at the top without being safe to select or complete.
Determines what happens when the user presses Enter without selecting a specific row.
Stricter than automatic selection. A candidate must:
www.).Note: Title, folder, substring, search, and literal URL candidates never inline-complete.
The wire-batch: line is emitted when more than one request completes within a single curl multi tick.
When you see RequestServer wire-batch: drained N completions in one curl multi tick followed by several wire: lines with identical timestamp prefixes, the clustering is cosmetic. The requests actually completed at different times, but they were all processed in the same loop.
To reconstruct true per-request completion times:
Take the drain timestamp from the batch line and subtract each request's drain delay (found in the wire^: line) from its wire^: timestamp.
RequestServer wire-batch: drained 3 completions in one curl multi tickUse RefPtr<T> for objects with multiple owners. Shared ownership is managed via reference counting. An object is deleted only when the last RefPtr pointing to it is destroyed.
NonnullRefPtr<T> is a variant that guarantees the pointer is never null.
Requirements for RefPtr:
To be compatible with RefPtr, a class T must implement ref() and unref(). The easiest way to achieve this is by inheriting from RefCounted<T>:
class Bar : public RefCounted<Bar> {
...
};RefPtr to a NonnullRefPtr, use RefPtr::release_nonnull() or dereference it with operator*.NonnullRefPtr can be assigned to a RefPtr, but not vice versa.Standard C++ constructors cannot return ErrorOr<T>. To handle fallible initialization, define a static function (conventionally named create) that returns ErrorOr<NonnullOwnPtr<T>> or ErrorOr<T>.
This method should:
ErrorOr.class Decompressor {
public:
static ErrorOr<NonnullOwnPtr<Decompressor>> create(NonnullOwnPtr<Core::Stream::Stream> stream)
{
auto buffer = TRY(CircularBuffer::create_empty(32 * KiB));
auto decompressor = TRY(adopt_nonnull_own_or_enomem(new (nothrow) Decompressor(move(stream), move(buffer))));
TRY(decompressor->initialize_settings_from_header());
return decompressor;
}
private:
Decompressor(NonnullOwnPtr<Core::Stream::Stream> stream, CircularBuffer buffer)
: m_stream(move(stream)), m_buffer(move(buffer)) {}
CircularBuffer m_buffer;
NonnullOwnPtr<Core::Stream::Stream> m_stream;
};LibWeb uses a three-layer model to expose C++ implementation objects to JavaScript, ensuring that the same implementation object can be observed through different realms or isolated worlds without losing identity within a specific world.
Web::Bindings::Wrappable: The C++ base class for any implementation object that can be reflected into JavaScript.PlatformObject wrappers: Generated by the WebIDL generator in Web::Bindings. These wrappers hold the actual implementation object and implement the Web-facing behavior.Web::Bindings::WrapperWorld: Owns the wrapper identity for a single observable world. Wrapping an object involves looking up or creating the wrapper within the caller's WrapperWorld.This architecture results in exactly one wrapper identity per (implementation object, WrapperWorld) pair.
Ladybird ports are categorized into two distinct layers:
UI Ports: These focus on the "browser frontend" or UI layer. This includes the browser window, tabs, address bar, and other visual elements. Currently supported UI ports are Qt6 (generic) and AppKit/Cocoa (macOS native).
Platform Ports: These focus on the underlying platform-specific code that interacts with the Operating System, such as file I/O, networking, and process management. Currently supported platform ports are GNU/Linux and macOS. An Android port is currently in progress.
LibCore's EventLoop is a cooperative multitasking scheduler used for handling application tasks concurrently on a single thread. It is an in-process loop that processes incoming events (signals, notifiers, file watchers, timers, etc.) by executing associated callbacks.
Key characteristics:
EventLoop::current() returns the topmost event loop on the calling thread.In the GUI application, the OutOfProcessWebView widget manages the lifecycle and communication of helper processes. The relationship between the GUI and the web content is structured as follows:
OutOfProcessWebView that implements the client side of the WebContent IPC (Inter-Process Communication) protocol.Web::Page object.Inside the WebContent process, the engine follows this hierarchy:
Web::Page: The top-level engine object.Web::Frame: The main frame (and subframes for <frame> or <iframe> elements).Web::Document: The root node of the DOM tree within a frame.