Replace the generated C++ legacy codec implementations with a
small Rust wrapper around encoding_rs.
This keeps the existing LibTextCodec API while moving label lookup,
legacy decode/encode, validation, and streaming decoder state to Rust.
The generated index data and generator are no longer needed.
It also fixes several TextDecoder EOF cases due to a more correct
implementation. encoding_rs finalizes decoders according to the
Encoding Standard, so incomplete UTF-8/Big5 tails and malformed
UTF-16 surrogate tails produce the required single replacement at
end-of-queue instead of being dropped, buffered, or double-counted
by our old hand-written decoders.
Bump the pinned ICU version from 78.2 to 78.3 — the current release — so
the build works on systems that already ship 78.3. And bump our vcpkg
baseline — because 78.3 is newer than our existing baseline. And pin
freetype to 2.13.3 — because the baseline update otherwise pulls in
2.14.3, which has font-rendering changes that break our layout tests.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/10145
Moving WebGL execution into the Compositor needs a serializable command
stream and a client-side proxy that can queue commands before sending
them over IPC. The existing generator metadata only described direct GL
wrappers, so generated code could not distinguish async commands from
sync calls or object factory methods.
This teaches the WebGL metadata and generators about command streams and
adds the unused LibWeb proxy/list types. No rendering behavior changes
yet; the later host wiring can build on these generated interfaces
without mixing the metadata churn into that commit.
Windows has a platform-native GPU stack based around Direct3D and DXGI.
The browser's Windows integration will need to share GPU resources with
Skia, ANGLE, and the UI process through that stack, especially when
backing stores move from bitmap readback to shared handles. Keeping
Vulkan as the Windows backend would put painting on a parallel API that
does not match the resources the rest of the native Windows pipeline
needs to exchange.
Remove the stale bytecode execution debug hook from Interpreter.cpp now
that bytecode dispatch always enters AsmInt directly. The remaining
bytecode dump flag is separate and still used by parser/codegen paths.
Add a browser-side model for top-level history entries and history step
coordinates. This gives the UI process a structure to mirror WebContent
history across process swaps.
Add debug dumping support alongside the model so traversal state can be
inspected while working on back and forward behavior.
LibWeb's WebGL implementation currently reaches ANGLE by calling glFoo()
throughout the WebGL context and extension code. That ties the WebGL
spec layer to the concrete GL executor. A future backend that records
operations, sends them to another process, or executes them from the
Compositor would otherwise need to duplicate the WebGL logic or edit
every call site again.
Introduce GLFunctions as an explicit boundary between WebGL semantics
and GL execution. GLFunctions.json lists the GL entry points used by the
implementation, and the generator emits one forwarding method per entry
point. OpenGLContext implements those methods today, so the current
in-process ANGLE path keeps the same behavior while all callers go
through a single replaceable interface.
That boundary is needed before canvas/WebGL rendering can move to the
Compositor: the WebGL context code can keep doing validation, state
tracking, and spec-visible error handling in LibWeb, while a later
implementation can record the same GL calls and replay them where the
canvas surface is produced. The JSON source also gives the recorder and
replayer one shared description of argument shapes, avoiding two
hand-written views of the GL API drifting apart.
Use a native QVulkanWindow child for Linux DMABUF presentation instead
of making WebContentView itself a QRhiWidget. This keeps BrowserWindow
on Qt's normal QWidget backing store path while sampling compositor
DMABUF backing stores directly in Vulkan.
Keep WebContentView's paintEvent as fallback for builds without Vulkan
DMABUF support and for cases where the Vulkan instance or window cannot
be created. Set an explicit Vulkan API version before creating the
shared QVulkanInstance so validation layers do not reject Qt defaults.
Replace the homegrown GIF parser and LZW decompressor with the wuffs
GIF decoder, which is memory-safe by construction and already used in
other engines via Skia.
One behavior change is that `loop_count()` now reports the correct
value, since the raw value stored in the file does not include the
first frane and should be incremented by 1 to be compatible with what
callers expect.
Replace the generated public suffix table and custom matcher with a
direct LibURL PublicSuffixData implementation backed by libpsl. This
drops our PSL download/generator path and uses the same library already
used by libcurl.
Performance is comparable before and after, while LibURL binary size
is smaller.
Pass -fstack-clash-protection for Linux builds. This asks the
compiler to probe large stack allocations incrementally so they cannot
skip over stack guard pages.
Pass -z relro and -z now to ELF linkers on Linux when the
linker supports them. This makes relocation sections read-only after
startup and disables lazy binding so the GOT is protected as well.
Replace the Lagom C++ bindings generator invocation with the new Python
generator under Meta/Generators/libweb_bindings.
Fold the exposed-interface generation into the same generator entry
point, and keep generated overload metadata using the existing LibIDL
types for now.
Problem: CI intermittently fails when a required-file download hiccups;
e.g., the WASM spec test suite fetch failed on both its primary URL and
the Web Archive fallback on the same run — breaking configure under CI.
Cause: download_file_multisource was trying each source only once — so a
single transient HTTP error could break the whole build. The WASM spec
test tarball was also being fetched fresh every run — rather than from
the shared download cache — so each build was exposed to that flakiness.
Fix: Retry each fetch a few times across all sources — for every config-
time download: the WASM spec tests, HSTS preload list, and public-suffix
list. Cache the WASM spec test tarball across CI runs — keyed by commit,
so it’s (re)fetched only once per commit bump.
Use libedit's readline-compatible interface for the JavaScript REPL so
line editing, history, and tab completion no longer depend on LibLine.
The REPL keeps its existing multiline input and completion behavior,
but no longer provides LibLine's live syntax highlighting.
Remove the unused LibLine dependency from the wasm utility and delete
the LibLine library from the build now that it has no remaining
consumers.
Enable -Wexit-time-destructors for all in-tree library targets and
update process-lifetime library statics so they no longer register
exit-time destructors. Long-lived caches, lookup tables, singleton
registries, and generated constants now use NeverDestroyed or leaked
references where the data is intended to live until process exit.
Update LibWeb, LibLine, and the binding generators so regenerated
sources follow the same rule instead of reintroducing destructed
statics.
Problem: After a git pull of master, builds fail with an error message
about multiple/duplicate rust_eh_personality definitions/symbols.
Cause: LibWeb links two Rust staticlibs: libweb_content_blocker_rust and
libweb_rust. Both bundle Rust’s standard library (std). When we re-pin
rust-toolchain.toml, a git pull moves a rustup user’s compiler — but we
were only rebuilding the crate whose .rs also changed. So that left one
crate on the old std, and the other crate on the new std.
Fix: Make the cargo custom commands also depend on rust-toolchain.toml
and rustc — so a toolchain change re-triggers every Rust crate.
Fixes https://github.com/LadybirdBrowser/ladybird/issues/9854
Fixes https://github.com/LadybirdBrowser/ladybird/issues/9643
These both require the same helper processes, and maintaining the same
list in multiple places is error-prone. For example, I spent too long
debugging why test-web was crashing, when the issue was that Compositor
hadn't been rebuilt as test-web didn't depend on it. That problem can
no longer happen if we define the same dependency list for both.
Pass source/build Libraries roots via --header-include-path and
canonicalize them in BindingsGenerator so generated dependency includes
use LibWeb/... paths instead of local absolute paths.
For example:
`#include "/home/shannon/ladybird/Libraries/LibWeb/DOMURL/DOMURL.h"`
becomes:
`#include "LibWeb/DOMURL/DOMURL.h"`
Add adblock-rust to a dedicated LibWeb content blocker Rust crate
and expose FFI entry points for creating an engine, matching network
requests, and producing cosmetic CSS. Export a string result type for
returning generated CSS to C++ callers.
Regenerate the Flatpak cargo source list for the new Rust
dependencies.
Port Bindings/Forward.h generation into
generate_window_or_worker_interfaces.py and remove the old C++
generate_forward_header path from BindingsGenerator.
Avoids us having to maintain a separate hardcoded list.
This does mean we don't support parsing of `decibel` but it's not used
anywhere yet and will be supported automatically when added to
Units.json
Create Libraries/LibWeb/Compositor and make the existing rendering
thread the first owner in that subsystem. Rename RenderingThread to
CompositorThread so later commits can grow it into the presentation
owner without leaving that vocabulary in HTML.
Keep display-list rasterization and delivery behavior unchanged in this
commit. Add COMPOSITOR_DEBUG to AK/Debug.h.in in the same step so
compositor diagnostics live beside the rest of the project-wide debug
toggles from the start of the stack.
Allow the WebIDL parser to accept files without a top-level interface,
and have the exposed-interface generator skip those modules.
With that in place, register support IDLs through
libweb_js_bindings() as well, including generated CSS IDLs from the
build directory, and remove the separate support-idl plumbing.
This is enabled now that the IDL generator rules have been simplified
so that every IDL file produces a corresponding header and cpp file.
Instead of sweeping all heap blocks in one go after marking, sweep
incrementally, one block at a time, interleaved with program execution.
This significantly reduces worst-case GC pause times by spreading
sweep work across multiple smaller time slices.
Sweep is driven by two complementary mechanisms:
1. Timer-based sweeping: A 16ms repeating timer drives background
sweep work, processing blocks for up to 5ms per timer fire.
2. Allocation-directed sweeping: Each allocator sweeps its own
pending blocks before creating new ones, ensuring forward
progress even without timer events.
Each allocator maintains its own list of blocks pending sweep,
and allocators with pending work are tracked in a separate list
for efficient timer-driven sweeping.
Key implementation details:
- Newly allocated cells during sweep are marked immediately to
prevent premature collection.
- Mark bits are cleared incrementally as each block is swept,
rather than in a separate pass over the entire heap.
- Finalization and weak reference processing remain stop-the-world
since they must complete atomically before any sweeping occurs.
Previously we were inconsistent by generating code for enum definitions
but not generating code for dictionaries. With future changes to the
IDL generator to expose helpers to convert to and from IDL values
this produced circular depdendencies. To solve this problem, also
generate the dictionary definitions in bindings headers.
Teach LibWeb codegen to emit a generated bindings header and
implementation for every IDL in the CMake inputs, including support only
IDLs.
For IDLs that do not yet produce bindings content, keep generation going
through IDLGenerators and emit empty placeholder files. This prepares
per-IDL generated definitions without changing the overall generation
flow.
This is entirely unused but still could be useful in the AppKit port.
Originally this was meant for Swift interop which is why it had support
for other platforms, but now it's causing issues on systems like
FreeBSD, so lets just gate it behind the only platform it's useful for.
We also assume that Objective C blocks and Arc are supported for the
AppKit port to build so no need to check for that in CMake.
Our Flatpak builds currently start failing once a commit ID no longer
matches with the commit pointed to by the configured `branch`. This is
becoming pretty annoying for Skia, since the `chrome/mXYZ` branches are
effectively moving targets.
Change the `branch` key in the Flatpak config to `x-branch`, which
removes the constraint and allows Flatpak to work with just the pinned
commit IDs. Change the linter to still use `x-branch` as the reference
to compare with our vcpkg configuration, so we make sure to still keep
things consistent between vcpkg and Flatpak.
