dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWebView/Application.h

461 lines
25 KiB
C
Raw Permalink Normal View History

LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
/*
* Copyright (c) 2024, Andrew Kaster <akaster@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibWebView: Add facilities to ask the user for a download directory If the Downloads directory exists, we will use it (note that this will respect the XDG_DOWNLOAD_DIR environment variable). Otherwise, we will ask the UI layer to retrieve a download directory from the user. This directory is not saved, so it will be re-prompted every time. Once a proper settings UI is complete, we will of course integrate with that for persistent settings.
2024-08-28 16:29:51 -03:00
#include <AK/ByteString.h>
Everywhere: Remove dynamic Mach bootstrap registration on macOS Registering multiple Mach port names with the bootstrap server at runtime is not how macOS expects it to be used — the bootstrap server is meant for static services, and the only reason we used it originally was so child processes could reach back to the UI process. Remove bootstrap_transport_over_socket(), which had both sides register dynamic names with the bootstrap server and exchange them over a socket. Instead, WebDriver and BrowserProcess connections now go through MachPortServer instances directly. When a non-child process contacts a MachPortServer, the server creates a port pair on demand (detected via sysctl ppid check) and returns the local half immediately. This keeps bootstrap server usage limited to the one original case: child processes looking up their parent's MachPortServer. WebDriver Session now runs its own MachPortServer per session. --webdriver-content-path becomes --webdriver-mach-server-name on macOS. Spare WebContent launches are skipped when a WebDriver session is active to avoid bootstrap races.
2026-03-22 15:59:08 -03:00
#include <AK/Function.h>
LibWebView: Add facilities to ask the user for a download directory If the Downloads directory exists, we will use it (note that this will respect the XDG_DOWNLOAD_DIR environment variable). Otherwise, we will ask the UI layer to retrieve a download directory from the user. This directory is not saved, so it will be re-prompted every time. Once a proper settings UI is complete, we will of course integrate with that for persistent settings.
2024-08-28 16:29:51 -03:00
#include <AK/LexicalPath.h>
#include <AK/Optional.h>
LibWebView: Share content blocker lists as buffers Add a repeatable blocker-list option that reads local list files in the browser process. The files are concatenated into one buffer and shared with WebContent through the content blocker IPC path when view options are applied. Parse the buffer in WebContent and reject malformed UTF-8 without replacing the currently installed rules.
2026-05-21 12:46:17 -03:00
#include <LibCore/AnonymousBuffer.h>
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
#include <LibCore/EventLoop.h>
LibWebView+WebContent: Monitor for system time zone changes This creates a TimeZoneWatcher in the UI process to inform all open WebContent processes when the time zone changes. The WebContent process will clear its time zone cache to retrieve a fresh zone the next time it is asked for one.
2024-08-24 13:15:20 -03:00
#include <LibCore/Forward.h>
LibDatabase+LibWebView: Extract our SQLite wrapper to its own library It currently lives in LibWebView as it was only used for cookies and local storage, both of which are managed in the UI process. Let's move it to its own library now to allow other processes to use it, without having to depend on LibWebView (and therefore LibWeb).
2025-10-07 15:35:22 -03:00
#include <LibDatabase/Forward.h>
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 10:09:47 -03:00
#include <LibDevTools/DevToolsDelegate.h>
#include <LibDevTools/Forward.h>
LibWebView+WebContent: Add feature-gated Compositor process backend We are moving toward an architecture where the browser owns a single process that holds the GPU context, so Skia resources can be shared across every renderer and WebContent processes can be sandboxed away from direct GPU access. A dedicated Compositor helper process is the first step. The earlier commits laid the foundation; this one turns the helper on as a selectable backend, gated behind --enable-compositor-process so the existing in-process path stays the shipping default. Default topology -- one compositor per WebContent, in-process: +---------+ | Browser | +---------+ / | \ v v v +---+ +---+ +---+ each WebContent runs its own |WC | |WC | |WC | CompositorThread on a dedicated |+C+| |+C+| |+C+| thread, with its own GPU context. +---+ +---+ +---+ Opt-in topology -- one single-threaded Compositor, shared by all WCs: +---------+ control +-------------------+ | Browser |<----------->| Compositor | +---------+ | (single thread, | / | \ | single GPU ctx, | v v v data | shared by all | [WC] [WC] [WC] ---------->| connected WCs) | +-------------------+ Three IPC channels carry the work in the opt-in topology. The existing Browser<->WebContent channel gains context allocation. A new Browser<->Compositor channel carries context lifetime, viewport, UI input, and presentation acks plus backing-store and frame upcalls. A new WebContent<->Compositor channel carries display lists, scroll state, video, compositor surfaces, async scrolling, presentation, and screenshots, with upcalls for delegated input and compositor loss.
2026-05-22 11:17:27 -03:00
#include <LibGfx/Point.h>
#include <LibGfx/Size.h>
Everywhere: Remove dynamic Mach bootstrap registration on macOS Registering multiple Mach port names with the bootstrap server at runtime is not how macOS expects it to be used — the bootstrap server is meant for static services, and the only reason we used it originally was so child processes could reach back to the UI process. Remove bootstrap_transport_over_socket(), which had both sides register dynamic names with the bootstrap server and exchange them over a socket. Instead, WebDriver and BrowserProcess connections now go through MachPortServer instances directly. When a non-child process contacts a MachPortServer, the server creates a port pair on demand (detected via sysctl ppid check) and returns the local half immediately. This keeps bootstrap server usage limited to the one original case: child processes looking up their parent's MachPortServer. WebDriver Session now runs its own MachPortServer per session. --webdriver-content-path becomes --webdriver-mach-server-name on macOS. Spare WebContent launches are skipped when a WebDriver session is active to avoid bootstrap races.
2026-03-22 15:59:08 -03:00
#include <LibIPC/Forward.h>
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 17:33:02 -03:00
#include <LibImageDecoderClient/Client.h>
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
#include <LibMain/Main.h>
LibWeb+LibWebView+LibRequests: Reduce dependency on LibIPC includes Let's try to include the IPC encoder/decoder stuff in fewer headers to make rebuilds more pleasant when editing these files.
2025-12-01 06:36:50 -03:00
#include <LibRequests/Forward.h>
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
#include <LibURL/URL.h>
LibWebView+UI: Generate the preferred color, contrast, and motion menus
2025-09-03 12:23:09 -03:00
#include <LibWeb/CSS/PreferredColorScheme.h>
#include <LibWeb/CSS/PreferredContrast.h>
#include <LibWeb/CSS/PreferredMotion.h>
LibWebView+UI: Move clipboard handling from the WebView to the App Clipboard handling largely has nothing to do with the individual web views. Rather, we interact with the system clipboard at the application level. So let's move these implementations to the Application.
2025-09-18 09:16:36 -03:00
#include <LibWeb/Clipboard/SystemClipboard.h>
LibWebView+WebContent: Allocate compositor contexts in Browser The helper process is a Browser-owned singleton, so Browser has to be the source of truth for which contexts exist: it is the only party that can register them with the helper, route backing-store and presentation upcalls back to the right WebContent and page, and reap them when a WebContent crashes. Move id allocation into Browser and have WebContent ask for ids over IPC, so the runtime switch in the next commit only has to select the backend. Behavior is preserved because Browser reproduces the previous deterministic-vs-fresh allocation logic and the in-process compositor still owns rendering.
2026-05-22 09:15:34 -03:00
#include <LibWeb/Compositor/Types.h>
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 10:08:24 -03:00
#include <LibWeb/HTML/ActivateTab.h>
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
#include <LibWebView/BookmarkStore.h>
LibWebView+UI: Add a context menu item to download images This introduces a simple FileDownloader to download files in the UI process from RequestServer. We use this to download the context menu image - this download is likely to hit the disk cache.
2026-02-03 10:00:15 -03:00
#include <LibWebView/FileDownloader.h>
LibWebView: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-02 00:55:11 -03:00
#include <LibWebView/Forward.h>
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
#include <LibWebView/Options.h>
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
#include <LibWebView/Process.h>
#include <LibWebView/ProcessManager.h>
LibWebView+UI: Introduce a persistent settings object This adds a WebView::Settings class to own persistent browser settings. In this first pass, it now owns the new tab page URL and search engine settings. For simplicitly, we currently use a JSON format for these settings. They are stored alongside the cookie database. As of this commit, the saved JSON will have the form: { "newTabPageURL": "about:blank", "searchEngine": { "name": "Google" } } (The search engine is an object to allow room for a future patch to implement custom search engine URLs.) For Qt, this replaces the management of these particular settings in the Qt settings UI. We will have an internal browser page to control these settings instead. In the future, we will want to port all settings to this new class. We will also want to allow UI-specific settings (such as whether the hamburger menu is displayed in Qt).
2025-03-20 13:59:44 -03:00
#include <LibWebView/Settings.h>
Everywhere: Implement persistence of localStorage using sqlite This change follows the pattern of our cookies persistence implementation: the "browser" process is responsible for interacting with the sqlite database, and WebContent communicates all storage operations via IPC. The new database table uses (storage_endpoint, storage_key, bottle_key) as the primary key. This design follows concepts from the https://storage.spec.whatwg.org/ and is intended to support reuse of the persistence layer for other APIs (e.g., CacheStorage, IndexedDB). For now, `storage_endpoint` is always "localStorage", `storage_key` is the website's origin, and `bottle_key` is the name of the localStorage key.
2025-06-08 18:35:46 -03:00
#include <LibWebView/StorageJar.h>
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
Everywhere: Replace Unix socket IPC transport with Mach ports on macOS On macOS, use Mach port messaging instead of Unix domain sockets for all IPC transport. This makes the transport capable of carrying Mach port rights as message attachments, which is a prerequisite for sending IOSurface handles over the main IPC channel (currently sent via a separate out-of-band path). It also avoids the need for the FD acknowledgement protocol that TransportSocket requires, since Mach port right transfers are atomic in the kernel. Three connection establishment patterns: - Spawned helper processes (WebContent, RequestServer, etc.) use the existing MachPortServer: the child sends its task port with a reply port, and the parent responds with a pre-created port pair. - Socket-bootstrapped connections (WebDriver, BrowserProcess) exchange Mach port names over the socket, then drop the socket. - Pre-created pairs for IPC tests and in-message transport transfer. Attachment on macOS now wraps a MachPort instead of a file descriptor, converting between the two via fileport_makeport()/fileport_makefd(). The LibIPC socket transport tests are disabled on macOS since they are socket-specific.
2026-03-19 15:42:05 -03:00
#if defined(AK_OS_MACOS)
# include <LibIPC/TransportBootstrapMach.h>
#endif
LibWebView+WebContent: Add feature-gated Compositor process backend We are moving toward an architecture where the browser owns a single process that holds the GPU context, so Skia resources can be shared across every renderer and WebContent processes can be sandboxed away from direct GPU access. A dedicated Compositor helper process is the first step. The earlier commits laid the foundation; this one turns the helper on as a selectable backend, gated behind --enable-compositor-process so the existing in-process path stays the shipping default. Default topology -- one compositor per WebContent, in-process: +---------+ | Browser | +---------+ / | \ v v v +---+ +---+ +---+ each WebContent runs its own |WC | |WC | |WC | CompositorThread on a dedicated |+C+| |+C+| |+C+| thread, with its own GPU context. +---+ +---+ +---+ Opt-in topology -- one single-threaded Compositor, shared by all WCs: +---------+ control +-------------------+ | Browser |<----------->| Compositor | +---------+ | (single thread, | / | \ | single GPU ctx, | v v v data | shared by all | [WC] [WC] [WC] ---------->| connected WCs) | +-------------------+ Three IPC channels carry the work in the opt-in topology. The existing Browser<->WebContent channel gains context allocation. A new Browser<->Compositor channel carries context lifetime, viewport, UI input, and presentation acks plus backing-store and frame upcalls. A new WebContent<->Compositor channel carries display lists, scroll state, video, compositor surfaces, async scrolling, presentation, and screenshots, with upcalls for delegated input and compositor loss.
2026-05-22 11:17:27 -03:00
namespace Web {
struct MouseEvent;
Compositor: Handle pinch zoom asynchronously Apply pinch zoom deltas to the compositor's visual viewport transform so the currently presented display list can respond without waiting for the WebContent main thread. Keep the normal WebContent pinch event path so the real VisualViewport state and DOM-visible events catch up after. Only take the compositor path when async scrolling is enabled and there are no blocking wheel listeners, since pinch zoom dispatches a synthetic wheel event that script may cancel. Coalesce queued pinch events in WebContent so main-thread catch-up can adopt multiple gesture deltas together. Use the compositor visual viewport transform for wheel hit testing and consume wheel deltas as visual viewport pan while zoomed. Scale the handoff to layout viewport scrolling by the inverse visual viewport scale, so touchpad momentum does not jump when the visual viewport hits an edge.
2026-06-14 16:30:28 -03:00
struct PinchEvent;
LibWebView+WebContent: Add feature-gated Compositor process backend We are moving toward an architecture where the browser owns a single process that holds the GPU context, so Skia resources can be shared across every renderer and WebContent processes can be sandboxed away from direct GPU access. A dedicated Compositor helper process is the first step. The earlier commits laid the foundation; this one turns the helper on as a selectable backend, gated behind --enable-compositor-process so the existing in-process path stays the shipping default. Default topology -- one compositor per WebContent, in-process: +---------+ | Browser | +---------+ / | \ v v v +---+ +---+ +---+ each WebContent runs its own |WC | |WC | |WC | CompositorThread on a dedicated |+C+| |+C+| |+C+| thread, with its own GPU context. +---+ +---+ +---+ Opt-in topology -- one single-threaded Compositor, shared by all WCs: +---------+ control +-------------------+ | Browser |<----------->| Compositor | +---------+ | (single thread, | / | \ | single GPU ctx, | v v v data | shared by all | [WC] [WC] [WC] ---------->| connected WCs) | +-------------------+ Three IPC channels carry the work in the opt-in topology. The existing Browser<->WebContent channel gains context allocation. A new Browser<->Compositor channel carries context lifetime, viewport, UI input, and presentation acks plus backing-store and frame upcalls. A new WebContent<->Compositor channel carries display lists, scroll state, video, compositor surfaces, async scrolling, presentation, and screenshots, with upcalls for delegated input and compositor loss.
2026-05-22 11:17:27 -03:00
}
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
namespace WebView {
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 13:37:05 -03:00
struct ApplicationSettingsObserver;
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
struct ApplicationBookmarkStoreObserver;
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 13:37:05 -03:00
LibWebView: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-02 00:55:11 -03:00
class WEBVIEW_API Application : public DevTools::DevToolsDelegate {
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
AK_MAKE_NONCOPYABLE(Application);
public:
virtual ~Application();
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 16:42:12 -03:00
ErrorOr<int> execute();
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
static Application& the() { return *s_the; }
LibWebView+UI: Introduce a persistent settings object This adds a WebView::Settings class to own persistent browser settings. In this first pass, it now owns the new tab page URL and search engine settings. For simplicitly, we currently use a JSON format for these settings. They are stored alongside the cookie database. As of this commit, the saved JSON will have the form: { "newTabPageURL": "about:blank", "searchEngine": { "name": "Google" } } (The search engine is an object to allow room for a future patch to implement custom search engine URLs.) For Qt, this replaces the management of these particular settings in the Qt settings UI. We will have an internal browser page to control these settings instead. In the future, we will want to port all settings to this new class. We will also want to allow UI-specific settings (such as whether the hamburger menu is displayed in Qt).
2025-03-20 13:59:44 -03:00
static Settings& settings() { return the().m_settings; }
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 17:56:52 -03:00
static BrowserOptions const& browser_options() { return the().m_browser_options; }
LibWebView: Add a command line flag to enable the HTTP disk cache This adds a RequestServerOptions structure to hold this option and the only other RS option we currently have (certificates).
2025-10-08 22:17:05 -03:00
static RequestServerOptions const& request_server_options() { return the().m_request_server_options; }
LibWebView+UI: Read and set echo server port in `HttpEchoServerFixture` This commit adds a "echo_server_port" property to `WebContentOptions`. Additionally, it makes `Application::web_content_options()` return a mutable reference instead of a const reference so that we can set the port value from the fixture.
2024-12-02 22:33:26 -03:00
static WebContentOptions& web_content_options() { return the().m_web_content_options; }
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 17:33:02 -03:00
static Requests::RequestClient& request_server_client() { return *the().m_request_server_client; }
static ImageDecoderClient::Client& image_decoder_client() { return *the().m_image_decoder_client; }
LibWebView: Add settings and actions to control vertical tabs This adds a setting to enable vertical tabs and to expand/collapse them if enabled. This setting is hidden for UIs that do not support them (which is every UI as of this commit).
2026-05-31 13:57:05 -03:00
virtual bool supports_vertical_tabs() const { return false; }
UI/Qt: Add an advanced setting to enable server-side decorations This adds a setting to disable our custom window decorations and let the system's window server paint the window instead.
2026-05-29 10:57:15 -03:00
virtual bool supports_server_side_window_decorations() const { return false; }
LibWebView: Add settings and actions to control vertical tabs This adds a setting to enable vertical tabs and to expand/collapse them if enabled. This setting is hidden for UIs that do not support them (which is every UI as of this commit).
2026-05-31 13:57:05 -03:00
void tab_settings_changed(Badge<ApplicationSettingsObserver>);
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
static BookmarkStore& bookmark_store() { return the().m_bookmark_store; }
void update_bookmark_action_for_current_web_view();
void bookmarks_changed(Badge<ApplicationBookmarkStoreObserver>);
void show_bookmarks_bar_changed(Badge<ApplicationSettingsObserver>);
LibWebView+UI: Add an about:bookmarks page to manage bookmarks This page renders the bookmarks as a tree and hook context menu events up to the UI's bookmarks bar context menus to allow editing bookmarks. Users can also drag-and-drop bookmark items around.
2026-04-06 20:08:00 -03:00
virtual void show_bookmark_context_menu(Gfx::IntPoint, Optional<BookmarkItem const&>, [[maybe_unused]] Optional<String const&> target_folder_id) { }
LibWebView+UI: Remove the clear-everything history store API This was only used by the AppKit UI's history menu. We have more fine- grained control over deleting history in about:settings#privacy.
2026-06-10 13:18:17 -03:00
static HistoryStore& history_store() { return *the().m_history_store; }
LibWebView+UI: Move the database and cookie jar to WebView::Application The main motivator here was noticing that --disable-sql-database did not work with AppKit. Rather than re-implementing this there, move ownership of these classes to WebView::Application, so that each UI does not need to individually worry about it.
2024-09-05 19:19:51 -03:00
static CookieJar& cookie_jar() { return *the().m_cookie_jar; }
LibWeb+LibHTTP+LibWebView: Implement HSTS When an HTTPS response carries a Strict-Transport-Security header, the received policy is now respected. Subsequent HTTP requests to a known HSTS host are upgraded to HTTPS before the fetch algorithm makes further decisions such as CORS and mixed content. Fixes tpexpress.co.uk, where an XHR redirects HTTPS -> HTTP -> HTTPS, relying on a HSTS policy received on the document response to avoid the CORS failure.
2026-03-26 14:04:33 -03:00
static HSTSStore& hsts_store() { return *the().m_hsts_store; }
Everywhere: Implement persistence of localStorage using sqlite This change follows the pattern of our cookies persistence implementation: the "browser" process is responsible for interacting with the sqlite database, and WebContent communicates all storage operations via IPC. The new database table uses (storage_endpoint, storage_key, bottle_key) as the primary key. This design follows concepts from the https://storage.spec.whatwg.org/ and is intended to support reuse of the persistence layer for other APIs (e.g., CacheStorage, IndexedDB). For now, `storage_endpoint` is always "localStorage", `storage_key` is the website's origin, and `bottle_key` is the name of the localStorage key.
2025-06-08 18:35:46 -03:00
static StorageJar& storage_jar() { return *the().m_storage_jar; }
LibWebView+UI: Move the database and cookie jar to WebView::Application The main motivator here was noticing that --disable-sql-database did not work with AppKit. Rather than re-implementing this there, move ownership of these classes to WebView::Application, so that each UI does not need to individually worry about it.
2024-09-05 19:19:51 -03:00
LibWebView: Defer creating services until after application init In particular, we need to defer creating the process manager until after we have decided whether or not to create a UI-specific event loop. If we create the process manager sooner, its event loop signal registration does not work, and we don't handle child processes exiting.
2025-06-11 08:32:37 -03:00
static ProcessManager& process_manager() { return *the().m_process_manager; }
Everywhere: Replace Unix socket IPC transport with Mach ports on macOS On macOS, use Mach port messaging instead of Unix domain sockets for all IPC transport. This makes the transport capable of carrying Mach port rights as message attachments, which is a prerequisite for sending IOSurface handles over the main IPC channel (currently sent via a separate out-of-band path). It also avoids the need for the FD acknowledgement protocol that TransportSocket requires, since Mach port right transfers are atomic in the kernel. Three connection establishment patterns: - Spawned helper processes (WebContent, RequestServer, etc.) use the existing MachPortServer: the child sends its task port with a reply port, and the parent responds with a pre-created port pair. - Socket-bootstrapped connections (WebDriver, BrowserProcess) exchange Mach port names over the socket, then drop the socket. - Pre-created pairs for IPC tests and in-message transport transfer. Attachment on macOS now wraps a MachPort instead of a file descriptor, converting between the two via fileport_makeport()/fileport_makefd(). The LibIPC socket transport tests are disabled on macOS since they are socket-specific.
2026-03-19 15:42:05 -03:00
#if defined(AK_OS_MACOS)
static IPC::TransportBootstrapMachServer& transport_bootstrap_server() { return the().m_transport_bootstrap_server; }
Everywhere: Remove dynamic Mach bootstrap registration on macOS Registering multiple Mach port names with the bootstrap server at runtime is not how macOS expects it to be used — the bootstrap server is meant for static services, and the only reason we used it originally was so child processes could reach back to the UI process. Remove bootstrap_transport_over_socket(), which had both sides register dynamic names with the bootstrap server and exchange them over a socket. Instead, WebDriver and BrowserProcess connections now go through MachPortServer instances directly. When a non-child process contacts a MachPortServer, the server creates a port pair on demand (detected via sysctl ppid check) and returns the local half immediately. This keeps bootstrap server usage limited to the one original case: child processes looking up their parent's MachPortServer. WebDriver Session now runs its own MachPortServer per session. --webdriver-content-path becomes --webdriver-mach-server-name on macOS. Spare WebContent launches are skipped when a WebDriver session is active to avoid bootstrap races.
2026-03-22 15:59:08 -03:00
void set_browser_process_transport_handler(Function<void(NonnullOwnPtr<IPC::Transport>)> handler);
Everywhere: Replace Unix socket IPC transport with Mach ports on macOS On macOS, use Mach port messaging instead of Unix domain sockets for all IPC transport. This makes the transport capable of carrying Mach port rights as message attachments, which is a prerequisite for sending IOSurface handles over the main IPC channel (currently sent via a separate out-of-band path). It also avoids the need for the FD acknowledgement protocol that TransportSocket requires, since Mach port right transfers are atomic in the kernel. Three connection establishment patterns: - Spawned helper processes (WebContent, RequestServer, etc.) use the existing MachPortServer: the child sends its task port with a reply port, and the parent responds with a pre-created port pair. - Socket-bootstrapped connections (WebDriver, BrowserProcess) exchange Mach port names over the socket, then drop the socket. - Pre-created pairs for IPC tests and in-message transport transfer. Attachment on macOS now wraps a MachPort instead of a file descriptor, converting between the two via fileport_makeport()/fileport_makefd(). The LibIPC socket transport tests are disabled on macOS since they are socket-specific.
2026-03-19 15:42:05 -03:00
#endif
LibWeb+LibWebView+WebContent: Convert about:processes to a WebUI
2025-03-24 10:50:12 -03:00
LibWebView: Create a spare WebContent process Since cross-site navigation is a pretty frequent task, creating a spare process is commonplace in other browsers to reduce the overhead of directing the target site to a new process. We store this process on the WebView application. If it is unavailable, we queue a task to create it later.
2025-03-09 19:01:25 -03:00
ErrorOr<NonnullRefPtr<WebContentClient>> launch_web_content_process(ViewImplementation&);
LibWebView+WebContent: Make page IDs browser-assigned Page IDs were allocated independently by each WebContent PageHost, starting at zero for every process. That made them unsuitable as a global identity for page-presenting compositor contexts, because the same numeric page ID could exist in multiple WebContent processes. Move page ID allocation to WebView::Application and initialize each WebContent process with its browser-assigned first page ID over IPC. New view requests now get a browser-assigned page ID before WebContent creates the PageClient, and PageHost no longer owns a local page counter. This gives page-presenting compositor contexts a stable global page identity, which will allow their context IDs to be derived from page IDs and simplify compositor context allocation in a follow-up.
2026-05-30 11:58:13 -03:00
u64 allocate_page_id();
Compositor+LibWeb+LibWebView: Simplify compositor context IDs Page-presenting compositor contexts still carried a separate tagged ID namespace and Browser-side page/context maps even though page IDs are now allocated globally by the UI process. That made context registration keep two ways to describe the same relationship and forced compositor IPC to pass an extra presentation bit. Use each page ID directly as its page-presenting compositor context ID and allocate non-page compositor contexts from the same Browser-owned counter. The registration path now sends only the optional page ID, and Compositor infers client presentation from that page ID.
2026-05-30 12:36:06 -03:00
Web::Compositor::CompositorContextId allocate_compositor_context_id();
Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
ErrorOr<void> connect_web_content_to_compositor(WebContentClient&);
Compositor+LibWeb+LibWebView: Simplify compositor context IDs Page-presenting compositor contexts still carried a separate tagged ID namespace and Browser-side page/context maps even though page IDs are now allocated globally by the UI process. That made context registration keep two ways to describe the same relationship and forced compositor IPC to pass an extra presentation bit. Use each page ID directly as its page-presenting compositor context ID and allocate non-page compositor contexts from the same Browser-owned counter. The registration path now sends only the optional page ID, and Compositor infers client presentation from that page ID.
2026-05-30 12:36:06 -03:00
void register_compositor_context(WebContentClient&, Web::Compositor::CompositorContextId, Optional<u64> page_id);
ErrorOr<void> try_register_compositor_context(WebContentClient&, Web::Compositor::CompositorContextId, Optional<u64> page_id);
LibWebView+WebContent: Add feature-gated Compositor process backend We are moving toward an architecture where the browser owns a single process that holds the GPU context, so Skia resources can be shared across every renderer and WebContent processes can be sandboxed away from direct GPU access. A dedicated Compositor helper process is the first step. The earlier commits laid the foundation; this one turns the helper on as a selectable backend, gated behind --enable-compositor-process so the existing in-process path stays the shipping default. Default topology -- one compositor per WebContent, in-process: +---------+ | Browser | +---------+ / | \ v v v +---+ +---+ +---+ each WebContent runs its own |WC | |WC | |WC | CompositorThread on a dedicated |+C+| |+C+| |+C+| thread, with its own GPU context. +---+ +---+ +---+ Opt-in topology -- one single-threaded Compositor, shared by all WCs: +---------+ control +-------------------+ | Browser |<----------->| Compositor | +---------+ | (single thread, | / | \ | single GPU ctx, | v v v data | shared by all | [WC] [WC] [WC] ---------->| connected WCs) | +-------------------+ Three IPC channels carry the work in the opt-in topology. The existing Browser<->WebContent channel gains context allocation. A new Browser<->Compositor channel carries context lifetime, viewport, UI input, and presentation acks plus backing-store and frame upcalls. A new WebContent<->Compositor channel carries display lists, scroll state, video, compositor surfaces, async scrolling, presentation, and screenshots, with upcalls for delegated input and compositor loss.
2026-05-22 11:17:27 -03:00
void update_compositor_viewport(Web::Compositor::CompositorContextId, Gfx::IntSize viewport_size, Web::Compositor::WindowResizingInProgress = Web::Compositor::WindowResizingInProgress::No);
LibWebView+Compositor+UI: Send display metadata to Compositor The browser process forwards the maximum frame rate to WebContent, but the compositor process had no copy of that display timing metadata or the display identity needed by compositor-local vsync. Add one compositor control IPC message carrying the optional display ID and refresh rate together, and store both values on each compositor context.
2026-05-28 14:04:22 -03:00
void update_compositor_display_metadata(Web::Compositor::CompositorContextId, Optional<u64> display_id, double refresh_rate);
LibWebView+WebContent: Add feature-gated Compositor process backend We are moving toward an architecture where the browser owns a single process that holds the GPU context, so Skia resources can be shared across every renderer and WebContent processes can be sandboxed away from direct GPU access. A dedicated Compositor helper process is the first step. The earlier commits laid the foundation; this one turns the helper on as a selectable backend, gated behind --enable-compositor-process so the existing in-process path stays the shipping default. Default topology -- one compositor per WebContent, in-process: +---------+ | Browser | +---------+ / | \ v v v +---+ +---+ +---+ each WebContent runs its own |WC | |WC | |WC | CompositorThread on a dedicated |+C+| |+C+| |+C+| thread, with its own GPU context. +---+ +---+ +---+ Opt-in topology -- one single-threaded Compositor, shared by all WCs: +---------+ control +-------------------+ | Browser |<----------->| Compositor | +---------+ | (single thread, | / | \ | single GPU ctx, | v v v data | shared by all | [WC] [WC] [WC] ---------->| connected WCs) | +-------------------+ Three IPC channels carry the work in the opt-in topology. The existing Browser<->WebContent channel gains context allocation. A new Browser<->Compositor channel carries context lifetime, viewport, UI input, and presentation acks plus backing-store and frame upcalls. A new WebContent<->Compositor channel carries display lists, scroll state, video, compositor surfaces, async scrolling, presentation, and screenshots, with upcalls for delegated input and compositor loss.
2026-05-22 11:17:27 -03:00
bool send_async_scroll_to_compositor(Web::Compositor::CompositorContextId, Gfx::FloatPoint position, Gfx::FloatPoint delta_in_device_pixels);
bool handle_mouse_event_in_compositor(Web::Compositor::CompositorContextId, Web::MouseEvent const&);
Compositor: Handle pinch zoom asynchronously Apply pinch zoom deltas to the compositor's visual viewport transform so the currently presented display list can respond without waiting for the WebContent main thread. Keep the normal WebContent pinch event path so the real VisualViewport state and DOM-visible events catch up after. Only take the compositor path when async scrolling is enabled and there are no blocking wheel listeners, since pinch zoom dispatches a synthetic wheel event that script may cancel. Coalesce queued pinch events in WebContent so main-thread catch-up can adopt multiple gesture deltas together. Use the compositor visual viewport transform for wheel hit testing and consume wheel deltas as visual viewport pan while zoomed. Scale the handoff to layout viewport scrolling by the inverse visual viewport scale, so touchpad momentum does not jump when the visual viewport hits an edge.
2026-06-14 16:30:28 -03:00
bool handle_pinch_event_in_compositor(Web::Compositor::CompositorContextId, Web::PinchEvent const&);
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
bool dispatch_mouse_event_to_web_content(Web::Compositor::CompositorContextId, Web::MouseEvent const&);
LibWebView+WebContent: Add feature-gated Compositor process backend We are moving toward an architecture where the browser owns a single process that holds the GPU context, so Skia resources can be shared across every renderer and WebContent processes can be sandboxed away from direct GPU access. A dedicated Compositor helper process is the first step. The earlier commits laid the foundation; this one turns the helper on as a selectable backend, gated behind --enable-compositor-process so the existing in-process path stays the shipping default. Default topology -- one compositor per WebContent, in-process: +---------+ | Browser | +---------+ / | \ v v v +---+ +---+ +---+ each WebContent runs its own |WC | |WC | |WC | CompositorThread on a dedicated |+C+| |+C+| |+C+| thread, with its own GPU context. +---+ +---+ +---+ Opt-in topology -- one single-threaded Compositor, shared by all WCs: +---------+ control +-------------------+ | Browser |<----------->| Compositor | +---------+ | (single thread, | / | \ | single GPU ctx, | v v v data | shared by all | [WC] [WC] [WC] ---------->| connected WCs) | +-------------------+ Three IPC channels carry the work in the opt-in topology. The existing Browser<->WebContent channel gains context allocation. A new Browser<->Compositor channel carries context lifetime, viewport, UI input, and presentation acks plus backing-store and frame upcalls. A new WebContent<->Compositor channel carries display lists, scroll state, video, compositor surfaces, async scrolling, presentation, and screenshots, with upcalls for delegated input and compositor loss.
2026-05-22 11:17:27 -03:00
void notify_compositor_presented_bitmap_ready_to_paint(Web::Compositor::CompositorContextId, i32 bitmap_id);
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 10:08:24 -03:00
LibWebView+UI: Extract some UI-specific displays to Application helpers This is preparation for moving application menus to LibWebView. We will need a way to display these dialogs from outside of the UI layer.
2025-09-04 09:53:57 -03:00
virtual Optional<ViewImplementation&> active_web_view() const { return {}; }
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 10:08:24 -03:00
virtual Optional<ViewImplementation&> open_blank_new_tab(Web::HTML::ActivateTab) const { return {}; }
LibWebView+UI/Qt: Reuse an existing history tab when viewing history Previously, the "View History" action always opened a new tab. We now switch to an existing `about:history` tab when one exists in the active window and fall back to opening a new tab otherwise.
2026-06-16 18:01:08 -03:00
virtual bool activate_tab_with_url(URL::URL const&) const { return false; }
UI/Qt: Keep macOS app alive without windows Disable Qt quit-on-last-window behavior on macOS and install an application-level menu so useful commands remain available after the last browser window closes. Reuse shared application actions and menus for Settings, Bookmarks, History, Help, and global appearance controls. Centralize window-aware commands such as New Tab, New Window, Open File, Open Location, and Reopen Recently Closed so the browser window and windowless app menu use the same behavior. Keep the location editor focused for new blank windows after the native window has been activated.
2026-06-21 07:28:23 -03:00
virtual void open_url_in_new_tab(URL::URL const&, Web::HTML::ActivateTab) const;
LibWebView: Add bookmark context menu items to open/copy bookmark URLs
2026-04-03 11:34:49 -03:00
void open_bookmark_in_new_tab(String const& bookmark_id, Web::HTML::ActivateTab) const;
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 17:33:02 -03:00
LibURL+LibWeb+LibWebView: Convert about:version to a proper WebUI Passing the browser command line and executable path to every WebContent process just in case we load about:version always felt a bit weird. We now use the WebUI framework to load this information on demand.
2026-04-20 18:27:15 -03:00
Main::Arguments const& command_line_arguments() const { return m_arguments; }
UI+LibWebView: Implement "Open Link in New Window"
2026-02-17 16:23:45 -03:00
virtual void open_url_in_new_window(URL::URL const& url);
LibURL+LibWeb+LibWebView: Convert about:version to a proper WebUI Passing the browser command line and executable path to every WebContent process just in case we load about:version always felt a bit weird. We now use the WebUI framework to load this information on demand.
2026-04-20 18:27:15 -03:00
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
void add_child_process(Process&&);
// FIXME: Should these methods be part of Application, instead of deferring to ProcessManager?
#if defined(AK_OS_MACH)
void set_process_mach_port(pid_t, Core::MachPort&&);
#endif
Optional<Process&> find_process(pid_t);
test-web: Add results directory and live terminal display - Add --results-dir CLI flag to specify output directory - Default to {tempdir}/test-web-results if not specified - Capture stdout/stderr from all helper processes (WebContent, RequestServer, ImageDecoder) to prevent output spam - Save captured output to per-test files in results directory - Save test diffs (expected vs actual) to results directory - Generate HTML index of failed tests with links to diffs - Display live-updating concurrent test status with progress bar - Defer warning messages until after test run completes
2026-01-13 07:23:09 -03:00
virtual bool should_capture_web_content_output() const { return false; }
LibWebView: Add facilities to ask the user for a download directory If the Downloads directory exists, we will use it (note that this will respect the XDG_DOWNLOAD_DIR environment variable). Otherwise, we will ask the UI layer to retrieve a download directory from the user. This directory is not saved, so it will be re-prompted every time. Once a proper settings UI is complete, we will of course integrate with that for persistent settings.
2024-08-28 16:29:51 -03:00
ErrorOr<LexicalPath> path_for_downloaded_file(StringView file) const;
LibWebView+UI: Extract some UI-specific displays to Application helpers This is preparation for moving application menus to LibWebView. We will need a way to display these dialogs from outside of the UI layer.
2025-09-04 09:53:57 -03:00
virtual void display_download_confirmation_dialog(StringView download_name, LexicalPath const& path) const;
virtual void display_error_dialog(StringView error_message) const;
LibWebView: Move headless clipboard management to LibWebView We only supported headless clipboard management in test-web. So when WPT tests the clipboard APIs, we would blindly try to access the Qt app, which does not exist. Note that the AppKit UI has no such restriction, as the NSPasteboard is accessible even without a GUI.
2025-10-10 11:11:56 -03:00
// FIXME: We should implement UI-agnostic platform APIs to interact with the system clipboard.
LibWeb+LibWebView+UI: Use the system selection text for primary pasting Commit 218d82cb65c636d1a56d6cb921ad1a4afe4f7202 added support for pasting text with the middle mouse button. But primary pasting is actually meant to interact with the "selection" clipboard, not the text clipboard.
2026-05-18 08:18:50 -03:00
enum class ClipboardType : u8 {
Text,
Selection,
};
LibWebView+UI: Disable primary paste on unsupported systems A selection clipboard is not available on all systems. The UI now controls whether this feature is available.
2026-05-21 09:30:18 -03:00
virtual bool supports_clipboard_type(ClipboardType) const;
LibWeb+LibWebView+UI: Use the system selection text for primary pasting Commit 218d82cb65c636d1a56d6cb921ad1a4afe4f7202 added support for pasting text with the middle mouse button. But primary pasting is actually meant to interact with the "selection" clipboard, not the text clipboard.
2026-05-18 08:18:50 -03:00
virtual Utf16String clipboard_text(ClipboardType = ClipboardType::Text) const;
LibWeb+LibWebView+UI: Update the selection keyboard on selection changes When the selected text on a page changes, update the system selection clipboard on supported systems (if primary pasting is enabled).
2026-05-27 12:43:35 -03:00
virtual void set_clipboard_text(String, ClipboardType = ClipboardType::Text);
LibWebView+UI: Disable primary paste on unsupported systems A selection clipboard is not available on all systems. The UI now controls whether this feature is available.
2026-05-21 09:30:18 -03:00
LibWebView: Move headless clipboard management to LibWebView We only supported headless clipboard management in test-web. So when WPT tests the clipboard APIs, we would blindly try to access the Qt app, which does not exist. Note that the AppKit UI has no such restriction, as the NSPasteboard is accessible even without a GUI.
2025-10-10 11:11:56 -03:00
virtual Vector<Web::Clipboard::SystemClipboardRepresentation> clipboard_entries() const;
virtual void insert_clipboard_entry(Web::Clipboard::SystemClipboardRepresentation);
LibWebView+UI: Move clipboard handling from the WebView to the App Clipboard handling largely has nothing to do with the individual web views. Rather, we interact with the system clipboard at the application level. So let's move these implementations to the Application.
2025-09-18 09:16:36 -03:00
LibWebView: Add a settings section to manage browsing data caches This adds a section to allow users to clear the HTTP disk cache and cookies / local storage / session storage. There are a few options to limit this action to a specific time range (e.g. "last hour"). The user is informed how much disk space is being used currently, and how much will be removed given the selected time range. The idea is that in the future, we can add more settings here to auto- delete data on exit, disable caching altogether, etc.
2025-11-02 20:44:17 -03:00
struct BrowsingDataSizes {
u64 cache_size_since_requested_time { 0 };
u64 total_cache_size { 0 };
u64 site_data_size_since_requested_time { 0 };
u64 total_site_data_size { 0 };
};
NonnullRefPtr<Core::Promise<BrowsingDataSizes>> estimate_browsing_data_size_accessed_since(UnixDateTime since);
struct ClearBrowsingDataOptions {
enum class Delete {
No,
Yes,
};
UnixDateTime since { UnixDateTime::earliest() };
Delete delete_cached_files { Delete::No };
LibWebView: Let Settings clear browsing history Route the existing Clear Browsing Data dialog through HistoryStore's time-range deletion path as well. That makes the Settings action remove visited pages from persisted history and from history-backed address bar suggestions instead of only touching cache and site data. Add a history checkbox to the dialog, thread its state through the Settings WebUI message, and cover remove_entries_accessed_since() for both transient and persisted stores in TestHistoryStore.
2026-04-11 20:16:07 -03:00
Delete delete_history { Delete::No };
LibWebView: Add a settings section to manage browsing data caches This adds a section to allow users to clear the HTTP disk cache and cookies / local storage / session storage. There are a few options to limit this action to a specific time range (e.g. "last hour"). The user is informed how much disk space is being used currently, and how much will be removed given the selected time range. The idea is that in the future, we can add more settings here to auto- delete data on exit, disable caching altogether, etc.
2025-11-02 20:44:17 -03:00
Delete delete_site_data { Delete::No };
};
void clear_browsing_data(ClearBrowsingDataOptions const&);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 09:20:14 -03:00
Action& reload_action() { return *m_reload_action; }
Action& copy_selection_action() { return *m_copy_selection_action; }
LibWeb+LibWebView+WebContent+UI: Add an action to cut text
2026-05-06 13:00:59 -03:00
Action& cut_selection_action() { return *m_cut_selection_action; }
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 09:20:14 -03:00
Action& paste_action() { return *m_paste_action; }
Action& select_all_action() { return *m_select_all_action; }
LibWebView+UI: Generate actions to open about: pages
2025-09-17 10:18:08 -03:00
Action& open_about_page_action() { return *m_open_about_page_action; }
Action& open_settings_page_action() { return *m_open_settings_page_action; }
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 09:20:14 -03:00
LibWebView+UI: Generate the zoom menu
2025-09-10 08:23:15 -03:00
Menu& zoom_menu() { return *m_zoom_menu; }
Action& reset_zoom_action() { return *m_reset_zoom_action; }
LibWebView+UI: Generate the preferred color, contrast, and motion menus
2025-09-03 12:23:09 -03:00
Menu& color_scheme_menu() { return *m_color_scheme_menu; }
Menu& contrast_menu() { return *m_contrast_menu; }
Menu& motion_menu() { return *m_motion_menu; }
LibWebView+UI: Generate the entire Inspect menu Now that all the actions in the Inspect menu are generated, we can generate the menu itself.
2025-09-17 11:22:23 -03:00
LibWebView: Add settings and actions to control vertical tabs This adds a setting to enable vertical tabs and to expand/collapse them if enabled. This setting is hidden for UIs that do not support them (which is every UI as of this commit).
2026-05-31 13:57:05 -03:00
Action& toggle_vertical_tabs_expanded_action() { return *m_toggle_vertical_tabs_expanded_action; }
LibWebView+UI/Qt: Move the show menu bar setting to LibWebView settings
2026-06-03 16:13:39 -03:00
Action& toggle_menu_bar_action() { return *m_toggle_menu_bar_action; }
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
Menu& bookmarks_menu() { return *m_bookmarks_menu; }
LibWebView: Add context menu items to interact with the bookmarks bar This adds hooks to add, edit, and delete bookmarks and folders.
2026-03-26 17:55:05 -03:00
Menu& bookmarks_bar_context_menu() { return *m_bookmarks_bar_context_menu; }
Menu& bookmark_context_menu() { return *m_bookmark_context_menu; }
Menu& bookmark_folder_context_menu() { return *m_bookmark_folder_context_menu; }
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
LibWebView+UI: Add a small history application menu This currently just contains a menu item to open about:history. But in the future, we can add a list of recently closed / recently visited pages as well.
2026-06-10 12:54:28 -03:00
Menu& history_menu() { return *m_history_menu; }
LibWebView+UI: Generate the entire Inspect menu Now that all the actions in the Inspect menu are generated, we can generate the menu itself.
2025-09-17 11:22:23 -03:00
Menu& inspect_menu() { return *m_inspect_menu; }
Action& view_source_action() { return *m_view_source_action; }
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 10:00:52 -03:00
Menu& debug_menu() { return *m_debug_menu; }
LibWebView+UI: Add a context menu item to download images This introduces a simple FileDownloader to download files in the UI process from RequestServer. We use this to download the context menu image - this download is likely to hit the disk cache.
2026-02-03 10:00:15 -03:00
FileDownloader& file_downloader() { return m_file_downloader; }
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 10:00:52 -03:00
void apply_view_options(Badge<ViewImplementation>, ViewImplementation&);
LibWebView+UI: Generate action to enable/disable DevTools
2025-09-17 11:03:01 -03:00
ErrorOr<void> toggle_devtools_enabled();
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 10:09:47 -03:00
void refresh_tab_list();
LibCore+LibWebView+UI/Qt: Support TimeZoneWatcher on Windows To detect system time zone changes on Windows, the event we need to look for is WM_TIMECHANGE. The problem is how the callback with said message actually gets invoked is very particular. (1) We must have an active message pump (event loop) for the message to ever be processed. (2) We must be a GUI application as WM_TIMECHANGE messages are seemingly sent to top level windows only. It doesn't say that in the docs for the event, but attempts of creating a LibTest-based application with a message pump and a message only window and never receiving the event point to that probably being true. This workaround is built off the fact that Qt's message pump defined internally in QEventDispatcherWin32::processEvents does in fact receive WM_TIMECHANGE events, even though it is not exposed as a QEvent::Type. Given the requirements stated above it makes sense that it works here as the message pump is executing in a QGuiApplication context. So we use a native event filter to hook into the unexposed WM_TIMECHANGE event and forward it along to the on_time_zone_changed() callback. Note that if a Windows GUI framework is done in the future, we'll have to re-add support to ensure the TimeZoneWatcher still gets invoked.
2025-09-16 22:06:00 -03:00
Optional<Core::TimeZoneWatcher&> time_zone_watcher();
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
protected:
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 20:20:46 -03:00
explicit Application(Optional<ByteString> ladybird_binary_path = {});
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 20:20:46 -03:00
ErrorOr<void> initialize(Main::Arguments const&);
LibWebView+UI: Don't declare a magic ctor for Application subclasses You would have to just know that you need to define the constructor with this declaration. Let's allow subclasses to define constructors as they see fit.
2025-06-10 20:13:03 -03:00
WebContent: Exit cleanly when browser IPC disconnects Exit WebContent immediately when either browser-side IPC peer disconnects. Plumb Unix process exit status through LibWebView so the browser process can tell clean owner-driven shutdown apart from renderer crashes. This keeps nonzero exits and signal deaths reported as crashes, while letting status 0 exits disappear without making test-web report the page as crashed.
2026-05-12 12:20:40 -03:00
virtual void process_did_exit(Process&&, Optional<int> exit_status);
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
virtual void create_platform_arguments(Core::ArgsParser&) { }
LibWebView+UI: Pass RequestServerOptions to Application implementations This will be needed by test-web.
2025-11-12 12:52:16 -03:00
virtual void create_platform_options(BrowserOptions&, RequestServerOptions&, WebContentOptions&) { }
LibCore: Keep main event loops alive Add an explicit initializer for process-lifetime event loops and use it for browser, helper service, and utility main loops. This preserves weak event loop references for cross-thread users while making main thread loop lifetime independent of normal program teardown.
2026-06-04 14:51:47 -03:00
virtual Core::EventLoop& create_platform_event_loop();
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
LibWebView+UI: Always ask the user where to save screenshots We currently always save screenshots to the Downloads folder. We will now always ask for a save location. This will just let an upcoming feature to save images from web pages behave the same way. We will want the user to be able to choose a file name, since the file name from the URL might be nonsense or already exist.
2026-02-02 20:54:59 -03:00
virtual Optional<ByteString> ask_user_for_download_path([[maybe_unused]] StringView file) const { return {}; }
LibWebView: Add facilities to ask the user for a download directory If the Downloads directory exists, we will use it (note that this will respect the XDG_DOWNLOAD_DIR environment variable). Otherwise, we will ask the UI layer to retrieve a download directory from the user. This directory is not saved, so it will be re-prompted every time. Once a proper settings UI is complete, we will of course integrate with that for persistent settings.
2024-08-28 16:29:51 -03:00
LibWebView: Add settings and actions to control vertical tabs This adds a setting to enable vertical tabs and to expand/collapse them if enabled. This setting is hidden for UIs that do not support them (which is every UI as of this commit).
2026-05-31 13:57:05 -03:00
virtual void update_tabs_display() const { }
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
virtual void rebuild_bookmarks_menu() const { }
LibWebView: Track recently closed tabs and windows Maintain a stack of URLs and when they were closed, and allow popping the most recent one. These are stored directly on HistoryStore instead of its Storage object, because they should never persist regardless of which backend we're using. Even so, we still clear them along with other history data.
2026-05-06 09:03:04 -03:00
virtual void on_recently_closed_entries_changed() const { }
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
LibWebView: Add context menu items to interact with the bookmarks bar This adds hooks to add, edit, and delete bookmarks and folders.
2026-03-26 17:55:05 -03:00
struct BookmarkID {
String id;
Optional<String> target_folder_id;
};
virtual Optional<BookmarkID> bookmark_item_id_for_context_menu() const { return {}; }
using BookmarkPromise = Core::Promise<BookmarkItem::Bookmark>;
virtual NonnullRefPtr<BookmarkPromise> display_add_bookmark_dialog() const;
virtual NonnullRefPtr<BookmarkPromise> display_edit_bookmark_dialog([[maybe_unused]] BookmarkItem::Bookmark const& current_bookmark) const;
using BookmarkFolderPromise = Core::Promise<BookmarkItem::Folder>;
virtual NonnullRefPtr<BookmarkFolderPromise> display_add_bookmark_folder_dialog() const;
virtual NonnullRefPtr<BookmarkFolderPromise> display_edit_bookmark_folder_dialog([[maybe_unused]] BookmarkItem::Folder const& current_folder) const;
LibWebView+UI: Generate action to enable/disable DevTools
2025-09-17 11:03:01 -03:00
virtual void on_devtools_enabled() const;
virtual void on_devtools_disabled() const;
LibWebView+UI: Do not create a QApplication in headless mode This is causing errors on the WPT runner, which does not have a display output. To do this requires shuffling around the Main::Arguments struct, as we now need access to it from overridden WebView::Application methods after construction.
2025-06-10 15:56:24 -03:00
Main::Arguments& arguments() { return m_arguments; }
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
private:
LibWebView+WebContent: Make page IDs browser-assigned Page IDs were allocated independently by each WebContent PageHost, starting at zero for every process. That made them unsuitable as a global identity for page-presenting compositor contexts, because the same numeric page ID could exist in multiple WebContent processes. Move page ID allocation to WebView::Application and initialize each WebContent process with its browser-assigned first page ID over IPC. New view requests now get a browser-assigned page ID before WebContent creates the PageClient, and PageHost no longer owns a local page counter. This gives page-presenting compositor contexts a stable global page identity, which will allow their context IDs to be derived from page IDs and simplify compositor context allocation in a follow-up.
2026-05-30 11:58:13 -03:00
ErrorOr<NonnullRefPtr<WebContentClient>> create_web_content_client(Optional<ViewImplementation&>, u64 initial_page_id);
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 20:20:46 -03:00
ErrorOr<void> launch_services();
LibWebView: Create a spare WebContent process Since cross-site navigation is a pretty frequent task, creating a spare process is commonplace in other browsers to reduce the overhead of directing the target site to a new process. We store this process on the WebView application. If it is unavailable, we queue a task to create it later.
2025-03-09 19:01:25 -03:00
void launch_spare_web_content_process();
Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
ErrorOr<void> launch_compositor_process();
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
void handle_compositor_process_death();
void recover_compositor_process();
Compositor+LibWebView: Add debug action to crash Compositor This is very useful for making sure Compositor process recovery works correctly.
2026-05-31 15:02:05 -03:00
void crash_compositor_process();
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 17:33:02 -03:00
ErrorOr<void> launch_request_server();
ErrorOr<void> launch_image_decoder_server();
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 10:09:47 -03:00
ErrorOr<void> launch_devtools_server();
LibWebView: Share content blocker lists as buffers Add a repeatable blocker-list option that reads local list files in the browser process. The files are concatenated into one buffer and shared with WebContent through the content blocker IPC path when view options are applied. Parse the buffer in WebContent and reject malformed UTF-8 without replacing the currently installed rules.
2026-05-21 12:46:17 -03:00
ErrorOr<void> load_content_blocker_lists();
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 10:09:47 -03:00
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 09:20:14 -03:00
void initialize_actions();
LibWebView: Add settings and actions to control vertical tabs This adds a setting to enable vertical tabs and to expand/collapse them if enabled. This setting is hidden for UIs that do not support them (which is every UI as of this commit).
2026-05-31 13:57:05 -03:00
void update_vertical_tabs_action();
LibWebView: Add context menu items to interact with the bookmarks bar This adds hooks to add, edit, and delete bookmarks and folders.
2026-03-26 17:55:05 -03:00
struct MenuData {
Menu& menu;
ReadonlySpan<BookmarkItem> items;
Optional<String const&> target_folder_id;
};
void create_bookmark_menu_items(Optional<MenuData> = {});
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 10:09:47 -03:00
virtual Vector<DevTools::TabDescription> tab_list() const override;
virtual Vector<DevTools::CSSProperty> css_property_list() const override;
LibDevTools+LibWebView: Support DevTools URL navigation Firefox's remote toolbox exposes an editable URL field for tab descriptors. Submitting that field sends navigateTo to the tab descriptor rather than the frame target. Handle the request in the tab actor, route it through the DevTools delegate, and reuse WebView's URL sanitizing and load path. Add protocol coverage so the toolbar navigation request stays wired up.
2026-05-29 11:09:35 -03:00
virtual void navigate_tab(DevTools::TabDescription const&, String const&) const override;
LibDevTools+LibWebView: Support DevTools page reloads Firefox reloads remote targets through the tab descriptor's reloadDescriptor request. We advertised support for that request, but left it unhandled, so Firefox could clear inspector state without causing Ladybird to reload the page. Route reloadDescriptor, and the legacy frame target reload request, through the DevTools delegate to WebView's reload path. This lets the existing navigation notifications publish the replacement inspector root after the reload completes.
2026-05-28 13:30:10 -03:00
virtual void reload_tab(DevTools::TabDescription const&, bool) const override;
LibDevTools+LibWebView: Support DevTools history navigation Firefox's inspector toolbar sends goBack and goForward requests to the tab descriptor when the descriptor advertises navigation support. Thread those requests through the DevTools delegate and reuse the existing WebView session-history traversal path. Keep the legacy frame-target requests working too, matching Firefox's window-global target compatibility surface. Add protocol coverage for both entry points so the advertised trait and deltas stay locked down.
2026-05-28 13:48:38 -03:00
virtual void traverse_the_history_by_delta(DevTools::TabDescription const&, int) const override;
LibWebView+LibDevTools: Populate DevTools cookies Firefox asks the cookies actor for rows after selecting a Storage host. Read the browser cookie jar through the DevTools delegate and serialize matching cookies with the fields Firefox expects. This keeps mutation support disabled, but makes existing cookies visible in the Storage panel.
2026-06-10 07:14:42 -03:00
virtual Vector<HTTP::Cookie::Cookie> cookies(DevTools::TabDescription const&) const override;
LibWebView: Add DevTools cookie mutation helpers DevTools needs to edit and delete cookies from the browser process. Add a small mutation surface to CookieJar and expose it through the DevTools delegate while preserving the existing cookie notification path.
2026-06-10 07:46:13 -03:00
virtual ErrorOr<void> set_cookie(DevTools::TabDescription const&, Optional<HTTP::Cookie::Cookie>, HTTP::Cookie::Cookie) const override;
virtual void delete_cookies(DevTools::TabDescription const&, Vector<HTTP::Cookie::Cookie>) const override;
LibDevTools: Report cookie storage changes Firefox keeps the Storage table current through storesUpdate messages from the storage actor. Forward browser cookie change notifications to the cookies actor and classify visible rows against a fresh cookie snapshot. The existing cookie-change notifications report cookies that are relevant to a specific page, whereas DevTools wants all cookies relevant for a host, so we end up having to provide two different sets of cookies to `notify_cookies_changed()`.
2026-06-10 07:19:44 -03:00
virtual void listen_for_host_cookie_changes(DevTools::TabDescription const&, OnHostCookieChange) const override;
virtual void stop_listening_for_host_cookie_changes(DevTools::TabDescription const&) const override;
LibDevTools: Populate DevTools Web Storage Firefox exposes localStorage and sessionStorage through the same storage actor protocol used by cookies. Add matching resources for the current tab so the Storage panel can list key/value pairs. Read the values through WebContent rather than directly from the browser process. Session storage lives in LibWeb, and using the same path for both stores keeps the actor independent of the backing store.
2026-06-10 12:15:21 -03:00
virtual void inspect_storage(DevTools::TabDescription const&, Web::StorageAPI::StorageEndpointType, OnStorageItemsReceived) const override;
LibDevTools: Allow editing Web Storage Firefox sends the same storage actor mutation requests for Web Storage that it uses for cookies. Handle addItem, editItem, removeItem, and removeAll for localStorage and sessionStorage actors. Apply the changes through the browser-process storage jar and emit the matching store update packets so the Storage panel stays current after a DevTools-initiated edit.
2026-06-10 12:27:25 -03:00
virtual ErrorOr<Optional<String>> set_storage_item(DevTools::TabDescription const&, Web::StorageAPI::StorageEndpointType, String const&, String const&, String const&) const override;
virtual ErrorOr<Optional<String>> remove_storage_item(DevTools::TabDescription const&, Web::StorageAPI::StorageEndpointType, String const&, String const&) const override;
virtual ErrorOr<void> clear_storage(DevTools::TabDescription const&, Web::StorageAPI::StorageEndpointType, String const&) const override;
LibWeb+LibDevTools: Report Web Storage changes Firefox keeps the Storage panel current by sending store update packets when localStorage or sessionStorage changes. Forward successful Web Storage mutations to the storage actors and emit the matching update or clear packet. Use listener IDs for storage updates so the local and session storage actors can subscribe independently.
2026-06-11 10:12:37 -03:00
virtual u64 add_storage_change_listener(DevTools::TabDescription const&, OnStorageChange) const override;
virtual void remove_storage_change_listener(DevTools::TabDescription const&, u64) const override;
LibDevTools+LibWeb: Show IndexedDB in DevTools Firefox asks the storage watcher for an indexed-db resource before it shows IndexedDB entries in the Storage panel. Add an IndexedDB actor and serialize the live LibWeb database registry on demand, so WebContent can return the host tree and table rows without duplicating database state. Use the LibWeb inspection helpers to read IndexedDB internals, and keep the Firefox protocol shape in LibDevTools. WebContent only forwards the serialized response over the existing DevTools IPC path.
2026-06-17 08:39:37 -03:00
virtual void inspect_indexed_database_storage(DevTools::TabDescription const&, OnIndexedDBInspectionComplete) const override;
virtual void inspect_indexed_database_objects(DevTools::TabDescription const&, String const&, Optional<JsonArray>, JsonObject, OnIndexedDBInspectionComplete) const override;
LibDevTools+LibWeb: Send IndexedDB change updates The Storage panel expects storesUpdate messages after watched storage changes. Summarize committed IndexedDB mutation logs into DevTools paths and forward them through WebContent so Firefox can refresh database, object-store, and record rows without polling. Firefox's behaviour is less than ideal here. A lot of things don't update automatically even inspecting a page in Firefox. Some things (like new databases) won't show up until you fully refresh the page. So that makes it a bit hard to know that we're doing things correctly. As far as I can tell, we are at least behaving as well as Firefox requires. We do have one workaround: Firefox doesn't display record updates without a manual refresh, and in fact any change messages for them show up as rows in the host's database table. So for now, we filter them out to avoid visual weirdness in the inspector.
2026-06-11 12:51:05 -03:00
virtual void delete_indexed_database(DevTools::TabDescription const&, String const&, String const&, OnIndexedDBInspectionComplete) const override;
virtual void clear_indexed_database_object_store(DevTools::TabDescription const&, String const&, String const&, OnIndexedDBInspectionComplete) const override;
virtual void delete_indexed_database_record(DevTools::TabDescription const&, String const&, String const&, OnIndexedDBInspectionComplete) const override;
virtual u64 add_indexed_database_change_listener(DevTools::TabDescription const&, OnIndexedDatabaseChange) const override;
virtual void remove_indexed_database_change_listener(DevTools::TabDescription const&, u64) const override;
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 18:22:12 -03:00
virtual void inspect_tab(DevTools::TabDescription const&, OnTabInspectionComplete) const override;
LibDevTools+LibWebView: Implement initial accessibility tree view This is enough for Firefox to display the Accessibility tab, containing our accessibility tree which can be inspected. Most information is blank for now. There's quite a bit of duplication between AccessibilityWalkerActor and WalkerActor - it might be worth trying to make a base class once the details are figured out. Frustratingly, the two don't work quite the same: for a lot of messages that would be sent to WalkerActor, the accessibility equivalent is sent to the AccessibilityNodeActor instead. Co-authored-by: Tim Flynn <trflynn89@pm.me>
2025-10-13 07:37:36 -03:00
virtual void inspect_accessibility_tree(DevTools::TabDescription const&, OnAccessibilityTreeInspectionComplete) const override;
LibDevTools+LibWebView+WebContent: Selectively fetch DOM node properties When we inspect a DOM node, we currently serialize many properties for that node, including its layout, computed style, used fonts, etc. Now that we aren't piggy-backing on the Inspector interface, we can instead only serialize the specific information required by DevTools.
2025-03-19 16:50:56 -03:00
virtual void listen_for_dom_properties(DevTools::TabDescription const&, OnDOMNodePropertiesReceived) const override;
virtual void stop_listening_for_dom_properties(DevTools::TabDescription const&) const override;
LibWebView+WebContent: Pass DOM inspection options Extend the existing DOM node inspection request with an options payload and carry it through the browser process, WebView, IPC, and WebContent. This lets later DevTools requests forward Firefox's top-level flags without changing any inspected-node behavior yet.
2026-06-04 11:17:17 -03:00
virtual void inspect_dom_node(DevTools::TabDescription const&, DOMNodeProperties::Type, Web::UniqueNodeID, Optional<Web::CSS::PseudoElement>, JsonObject options = {}) const override;
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 18:22:12 -03:00
virtual void clear_inspected_dom_node(DevTools::TabDescription const&) const override;
LibWebView: Wire node picker state to hit testing LibWebView owns the active page connection and bridges the DevTools delegate to WebContent. Track picker state there, translate UI hover, preview, pick, and cancel requests into hit-test IPC, and forward the resulting node ids back through the DevTools callback. Keeping the request bookkeeping in LibWebView also lets the platform UI frontends share the same picker behavior.
2026-05-28 08:14:41 -03:00
virtual void start_node_picker(DevTools::TabDescription const&, OnNodePickerEvent) const override;
virtual void stop_node_picker(DevTools::TabDescription const&) const override;
virtual void clear_node_picker(DevTools::TabDescription const&) const override;
DevTools: Add grid layout WebContent plumbing Add IPC structures and requests for inspecting grid layout data from WebContent. WebView forwards the async replies to LibDevTools and exposes the grid highlighter hooks used by the protocol layer. Parse Firefox grid highlighter options in WebContent and store them with the active grid highlight.
2026-05-22 10:42:29 -03:00
virtual void inspect_grid_layouts(DevTools::TabDescription const&, Web::UniqueNodeID, OnGridLayoutsReceived) const override;
virtual void inspect_current_grid(DevTools::TabDescription const&, Web::UniqueNodeID, OnCurrentGridReceived) const override;
WebContent+LibWebView: Add flexbox inspection plumbing
2026-05-27 12:41:13 -03:00
virtual void inspect_current_flexbox(DevTools::TabDescription const&, Web::UniqueNodeID, bool, OnCurrentFlexboxReceived) const override;
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 13:56:46 -03:00
virtual void highlight_dom_node(DevTools::TabDescription const&, Web::UniqueNodeID, Optional<Web::CSS::PseudoElement>) const override;
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 18:22:12 -03:00
virtual void clear_highlighted_dom_node(DevTools::TabDescription const&) const override;
DevTools+WebContent: Support the flexbox highlighter
2026-05-27 13:12:14 -03:00
virtual void highlight_flexbox(DevTools::TabDescription const&, Web::UniqueNodeID, JsonValue) const override;
virtual void clear_flexbox_highlight(DevTools::TabDescription const&, Web::UniqueNodeID) const override;
DevTools: Add grid layout WebContent plumbing Add IPC structures and requests for inspecting grid layout data from WebContent. WebView forwards the async replies to LibDevTools and exposes the grid highlighter hooks used by the protocol layer. Parse Firefox grid highlighter options in WebContent and store them with the active grid highlight.
2026-05-22 10:42:29 -03:00
virtual void highlight_grid(DevTools::TabDescription const&, Web::UniqueNodeID, JsonValue) const override;
virtual void clear_grid_highlight(DevTools::TabDescription const&, Web::UniqueNodeID) const override;
LibDevTools+LibWebView: Inform the DevTools client about DOM mutations
2025-03-06 21:56:03 -03:00
virtual void listen_for_dom_mutations(DevTools::TabDescription const&, OnDOMMutationReceived) const override;
virtual void stop_listening_for_dom_mutations(DevTools::TabDescription const&) const override;
LibDevTools+LibWebView+WebContent: Implement getting DOM node inner HTML This is used by DevTools to copy the inner HTML to the clipboard.
2025-03-10 19:15:31 -03:00
virtual void get_dom_node_inner_html(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeHTMLReceived) const override;
LibDevTools+LibWebView+WebContent: Implement editing DOM node HTML These commands are used for the "Edit As HTML" feature in DevTools. This renames our existing HTML getter IPC to indicate that it is for outer HTML. DevTools will need a separate inner HTML getter.
2025-03-10 18:36:41 -03:00
virtual void get_dom_node_outer_html(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeHTMLReceived) const override;
virtual void set_dom_node_outer_html(DevTools::TabDescription const&, Web::UniqueNodeID, String const&, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 13:00:03 -03:00
virtual void set_dom_node_text(DevTools::TabDescription const&, Web::UniqueNodeID, String const&, OnDOMNodeEditComplete) const override;
virtual void set_dom_node_tag(DevTools::TabDescription const&, Web::UniqueNodeID, String const&, OnDOMNodeEditComplete) const override;
virtual void add_dom_node_attributes(DevTools::TabDescription const&, Web::UniqueNodeID, ReadonlySpan<Attribute>, OnDOMNodeEditComplete) const override;
virtual void replace_dom_node_attribute(DevTools::TabDescription const&, Web::UniqueNodeID, String const&, ReadonlySpan<Attribute>, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Implement requests to create DOM nodes This requires a couple of amendments to the DOM node serialization. Namely, we need to include the HTML namespace, otherwise the context menu item to create a new node is disabled.
2025-03-07 11:19:28 -03:00
virtual void create_child_element(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView+WebContent: Implement moving DOM nodes This allows for click-and-dragging DOM nodes in DevTools to move them.
2025-03-10 19:01:29 -03:00
virtual void insert_dom_node_before(DevTools::TabDescription const&, Web::UniqueNodeID, Web::UniqueNodeID, Optional<Web::UniqueNodeID>, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Implement requests to clone DOM nodes
2025-03-07 11:44:24 -03:00
virtual void clone_dom_node(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Implement requests to delete DOM nodes
2025-03-06 22:08:27 -03:00
virtual void remove_dom_node(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Implement getting document style sheets
2025-03-11 18:14:54 -03:00
virtual void retrieve_style_sheets(DevTools::TabDescription const&, OnStyleSheetsReceived) const override;
virtual void retrieve_style_sheet_source(DevTools::TabDescription const&, Web::CSS::StyleSheetIdentifier const&) const override;
virtual void listen_for_style_sheet_sources(DevTools::TabDescription const&, OnStyleSheetSourceReceived) const override;
virtual void stop_listening_for_style_sheet_sources(DevTools::TabDescription const&) const override;
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 13:00:03 -03:00
virtual void evaluate_javascript(DevTools::TabDescription const&, String const&, OnScriptEvaluationComplete) const override;
LibDevTools: Stream console messages instead of polling by index Previously, console messages were sent using an index-based system where DevTools would be notified of new message indices and then request them in batches. This created synchronization issues during page navigation when the WebContent process resets while DevTools still has stale index state. This changes to a push-based model where console messages are sent immediately as resources when they are logged, matching how Firefox DevTools handles console messages. Each message is pushed through IPC and forwarded to DevTools as a "console-message" or "error-message" resource. This eliminates the need for index tracking in FrameActor and simplifies the entire console message pipeline from WebContent through to DevTools.
2026-01-14 16:13:24 -03:00
virtual void listen_for_console_messages(DevTools::TabDescription const&, OnConsoleMessage) const override;
LibWebView+WebContent: Implement basic DevTools console support
2025-03-04 10:48:20 -03:00
virtual void stop_listening_for_console_messages(DevTools::TabDescription const&) const override;
LibDevTools: Add request and response body viewing to network panel This adds support for viewing request payloads (POST data) and response bodies in the Firefox DevTools network panel. Request bodies are captured when network requests start and passed through IPC to the NetworkEventActor, which returns them via the getRequestPostData protocol method. Response bodies are streamed via a new IPC message as data is received, accumulated in NetworkEventActor (with a 10MB size limit to prevent memory issues), and returned via getResponseContent. Text content is returned as UTF-8, while binary content (images, etc.) is base64.
2026-01-14 16:47:04 -03:00
virtual void listen_for_network_events(DevTools::TabDescription const&, OnNetworkRequestStarted, OnNetworkResponseHeadersReceived, OnNetworkResponseBodyReceived, OnNetworkRequestFinished) const override;
LibDevTools: Add Firefox DevTools network monitoring support Hook ResourceLoader to emit network request lifecycle events through IPC to the UI process, where FrameActor creates NetworkEventActor instances that serialize requests using Firefox's Remote Debug Protocol. The Network panel now shows requests with method, URL, status, MIME type, size, and timing information. Several features remain stubbed (POST data, response content, cause detection) marked with FIXMEs.
2026-01-14 14:43:48 -03:00
virtual void stop_listening_for_network_events(DevTools::TabDescription const&) const override;
LibDevTools: Send navigation events to Firefox DevTools When a page navigates, send document-event resources with "will-navigate" and tabNavigated messages so Firefox DevTools can follow along and clear the Network panel appropriately.
2026-01-14 15:03:16 -03:00
virtual void listen_for_navigation_events(DevTools::TabDescription const&, OnNavigationStarted, OnNavigationFinished) const override;
virtual void stop_listening_for_navigation_events(DevTools::TabDescription const&) const override;
LibDevTools: Only send network response bodies when DevTools connected To avoid unnecessary IPC traffic, we now only send network response bodies when a DevTools client is connected. This requires tracking DevTools connection state in ViewImplementation so we can propagate it to new WebContent processes created during cross-site navigation.
2026-01-15 10:28:42 -03:00
virtual void did_connect_devtools_client(DevTools::TabDescription const&) const override;
virtual void did_disconnect_devtools_client(DevTools::TabDescription const&) const override;
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 17:33:02 -03:00
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
static Application* s_the;
LibWebView+UI: Introduce a persistent settings object This adds a WebView::Settings class to own persistent browser settings. In this first pass, it now owns the new tab page URL and search engine settings. For simplicitly, we currently use a JSON format for these settings. They are stored alongside the cookie database. As of this commit, the saved JSON will have the form: { "newTabPageURL": "about:blank", "searchEngine": { "name": "Google" } } (The search engine is an object to allow room for a future patch to implement custom search engine URLs.) For Qt, this replaces the management of these particular settings in the Qt settings UI. We will have an internal browser page to control these settings instead. In the future, we will want to port all settings to this new class. We will also want to allow UI-specific settings (such as whether the hamburger menu is displayed in Qt).
2025-03-20 13:59:44 -03:00
Settings m_settings;
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 13:37:05 -03:00
OwnPtr<ApplicationSettingsObserver> m_settings_observer;
LibWebView+UI: Introduce a persistent settings object This adds a WebView::Settings class to own persistent browser settings. In this first pass, it now owns the new tab page URL and search engine settings. For simplicitly, we currently use a JSON format for these settings. They are stored alongside the cookie database. As of this commit, the saved JSON will have the form: { "newTabPageURL": "about:blank", "searchEngine": { "name": "Google" } } (The search engine is an object to allow room for a future patch to implement custom search engine URLs.) For Qt, this replaces the management of these particular settings in the Qt settings UI. We will have an internal browser page to control these settings instead. In the future, we will want to port all settings to this new class. We will also want to allow UI-specific settings (such as whether the hamburger menu is displayed in Qt).
2025-03-20 13:59:44 -03:00
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
BookmarkStore m_bookmark_store;
OwnPtr<ApplicationBookmarkStoreObserver> m_bookmark_store_observer;
LibWebView: Add history-backed location autocomplete Teach LibWebView autocomplete to query HistoryStore before falling back to remote engines and move the wiring out of the AppKit frontend. Refine matching so scheme and www. boilerplate do not dominate results, short title and substring queries stay quiet, and history tracing can explain what the ranking code is doing.
2026-04-11 19:32:29 -03:00
OwnPtr<HistoryStore> m_history_store;
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
LibWebView+UI: Do not create a QApplication in headless mode This is causing errors on the WPT runner, which does not have a display output. To do this requires shuffling around the Main::Arguments struct, as we now need access to it from overridden WebView::Application methods after construction.
2025-06-10 15:56:24 -03:00
Main::Arguments m_arguments;
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 17:56:52 -03:00
BrowserOptions m_browser_options;
LibWebView: Add a command line flag to enable the HTTP disk cache This adds a RequestServerOptions structure to hold this option and the only other RS option we currently have (certificates).
2025-10-08 22:17:05 -03:00
RequestServerOptions m_request_server_options;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
WebContentOptions m_web_content_options;
LibWebView: Share content blocker lists as buffers Add a repeatable blocker-list option that reads local list files in the browser process. The files are concatenated into one buffer and shared with WebContent through the content blocker IPC path when view options are applied. Parse the buffer in WebContent and reject malformed UTF-8 without replacing the currently installed rules.
2026-05-21 12:46:17 -03:00
Optional<Core::AnonymousBuffer> m_content_blocker_list_buffer;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 17:33:02 -03:00
RefPtr<Requests::RequestClient> m_request_server_client;
RefPtr<ImageDecoderClient::Client> m_image_decoder_client;
Compositor+LibWebView+WebContent: Scaffold opt-in Compositor process The compositor is moving into a dedicated helper process. That requires a process to launch, channels for Browser and WebContent to talk to it over, and client proxies on each side. Land all of that as an inert scaffold first, gated behind --enable-compositor-process, so the default rendering path is unchanged and later commits can fill in the protocol, the service-side state, and the runtime switch against a stable target.
2026-05-22 11:02:42 -03:00
RefPtr<CompositorClient> m_compositor_client;
LibWeb+LibWebView+WebContent: Recover after Compositor process crashes The browser previously treated the out-of-process Compositor as fatal. Restart the shared Compositor from the browser process, reconnect process-backed WebContent clients, recreate compositor contexts, restore viewport state, and ask WebContent to repaint and republish canvas and media resources. WebContent now marks its compositor connection lost, returns conservative values for synchronous compositor queries while reconnecting, and drops outgoing updates until the replacement transport arrives. Synchronous input queries through the compositor control connection now use fallible IPC. If the Compositor exits after the open check or before the sync reply arrives, scroll and mouse handling report that the Compositor did not handle the event and let the normal WebContent fallback run. Mouse events queued while the Compositor is unavailable now fall back to direct WebContent dispatch. This keeps input completion in step with the pending-event queue. Recovery is capped at three automatic restarts. If the restart limit is exceeded, if restart, reconnect, or context recreation fails, or if the replacement Compositor exits during active recovery, the browser crashes instead of switching process-backed views to a fallback path.
2026-05-23 22:36:24 -03:00
size_t m_compositor_restart_count { 0 };
enum class CompositorRecoveryState {
Idle,
Queued,
Recovering,
};
CompositorRecoveryState m_compositor_recovery_state { CompositorRecoveryState::Idle };
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 17:33:02 -03:00
LibWebView: Create a spare WebContent process Since cross-site navigation is a pretty frequent task, creating a spare process is commonplace in other browsers to reduce the overhead of directing the target site to a new process. We store this process on the WebView application. If it is unavailable, we queue a task to create it later.
2025-03-09 19:01:25 -03:00
RefPtr<WebContentClient> m_spare_web_content_process;
bool m_has_queued_task_to_launch_spare_web_content_process { false };
Compositor+LibWeb+LibWebView: Simplify compositor context IDs Page-presenting compositor contexts still carried a separate tagged ID namespace and Browser-side page/context maps even though page IDs are now allocated globally by the UI process. That made context registration keep two ways to describe the same relationship and forced compositor IPC to pass an extra presentation bit. Use each page ID directly as its page-presenting compositor context ID and allocate non-page compositor contexts from the same Browser-owned counter. The registration path now sends only the optional page ID, and Compositor infers client presentation from that page ID.
2026-05-30 12:36:06 -03:00
u64 m_next_page_or_compositor_context_id { 1 };
LibWebView: Create a spare WebContent process Since cross-site navigation is a pretty frequent task, creating a spare process is commonplace in other browsers to reduce the overhead of directing the target site to a new process. We store this process on the WebView application. If it is unavailable, we queue a task to create it later.
2025-03-09 19:01:25 -03:00
LibDatabase+LibWebView: Extract our SQLite wrapper to its own library It currently lives in LibWebView as it was only used for cookies and local storage, both of which are managed in the UI process. Let's move it to its own library now to allow other processes to use it, without having to depend on LibWebView (and therefore LibWeb).
2025-10-07 15:35:22 -03:00
RefPtr<Database::Database> m_database;
LibWebView: Add history-backed location autocomplete Teach LibWebView autocomplete to query HistoryStore before falling back to remote engines and move the wiring out of the AppKit frontend. Refine matching so scheme and www. boilerplate do not dominate results, short title and substring queries stay quiet, and history tracing can explain what the ranking code is doing.
2026-04-11 19:32:29 -03:00
RefPtr<Database::Database> m_history_database;
LibWebView+UI: Move the database and cookie jar to WebView::Application The main motivator here was noticing that --disable-sql-database did not work with AppKit. Rather than re-implementing this there, move ownership of these classes to WebView::Application, so that each UI does not need to individually worry about it.
2024-09-05 19:19:51 -03:00
OwnPtr<CookieJar> m_cookie_jar;
LibWeb+LibHTTP+LibWebView: Implement HSTS When an HTTPS response carries a Strict-Transport-Security header, the received policy is now respected. Subsequent HTTP requests to a known HSTS host are upgraded to HTTPS before the fetch algorithm makes further decisions such as CORS and mixed content. Fixes tpexpress.co.uk, where an XHR redirects HTTPS -> HTTP -> HTTPS, relying on a HSTS policy received on the document response to avoid the CORS failure.
2026-03-26 14:04:33 -03:00
OwnPtr<HSTSStore> m_hsts_store;
Everywhere: Implement persistence of localStorage using sqlite This change follows the pattern of our cookies persistence implementation: the "browser" process is responsible for interacting with the sqlite database, and WebContent communicates all storage operations via IPC. The new database table uses (storage_endpoint, storage_key, bottle_key) as the primary key. This design follows concepts from the https://storage.spec.whatwg.org/ and is intended to support reuse of the persistence layer for other APIs (e.g., CacheStorage, IndexedDB). For now, `storage_endpoint` is always "localStorage", `storage_key` is the website's origin, and `bottle_key` is the name of the localStorage key.
2025-06-08 18:35:46 -03:00
OwnPtr<StorageJar> m_storage_jar;
LibWebView+UI: Move the database and cookie jar to WebView::Application The main motivator here was noticing that --disable-sql-database did not work with AppKit. Rather than re-implementing this there, move ownership of these classes to WebView::Application, so that each UI does not need to individually worry about it.
2024-09-05 19:19:51 -03:00
LibWebView+WebContent: Monitor for system time zone changes This creates a TimeZoneWatcher in the UI process to inform all open WebContent processes when the time zone changes. The WebContent process will clear its time zone cache to retrieve a fresh zone the next time it is asked for one.
2024-08-24 13:15:20 -03:00
OwnPtr<Core::TimeZoneWatcher> m_time_zone_watcher;
LibCore: Keep main event loops alive Add an explicit initializer for process-lifetime event loops and use it for browser, helper service, and utility main loops. This preserves weak event loop references for cross-thread users while making main thread loop lifetime independent of normal program teardown.
2026-06-04 14:51:47 -03:00
Core::EventLoop* m_event_loop { nullptr };
LibWebView: Defer creating services until after application init In particular, we need to defer creating the process manager until after we have decided whether or not to create a UI-specific event loop. If we create the process manager sooner, its event loop signal registration does not work, and we don't handle child processes exiting.
2025-06-11 08:32:37 -03:00
OwnPtr<ProcessManager> m_process_manager;
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 10:09:47 -03:00
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 09:20:14 -03:00
RefPtr<Action> m_reload_action;
RefPtr<Action> m_copy_selection_action;
LibWeb+LibWebView+WebContent+UI: Add an action to cut text
2026-05-06 13:00:59 -03:00
RefPtr<Action> m_cut_selection_action;
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 09:20:14 -03:00
RefPtr<Action> m_paste_action;
RefPtr<Action> m_select_all_action;
LibWebView+UI: Generate actions to open about: pages
2025-09-17 10:18:08 -03:00
RefPtr<Action> m_open_about_page_action;
RefPtr<Action> m_open_settings_page_action;
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 09:20:14 -03:00
LibWebView+UI: Generate the zoom menu
2025-09-10 08:23:15 -03:00
RefPtr<Menu> m_zoom_menu;
RefPtr<Action> m_reset_zoom_action;
LibWebView+UI: Generate the preferred color, contrast, and motion menus
2025-09-03 12:23:09 -03:00
RefPtr<Menu> m_color_scheme_menu;
Web::CSS::PreferredColorScheme m_color_scheme { Web::CSS::PreferredColorScheme::Auto };
RefPtr<Menu> m_contrast_menu;
Web::CSS::PreferredContrast m_contrast { Web::CSS::PreferredContrast::Auto };
RefPtr<Menu> m_motion_menu;
Web::CSS::PreferredMotion m_motion { Web::CSS::PreferredMotion::Auto };
LibWebView: Add settings and actions to control vertical tabs This adds a setting to enable vertical tabs and to expand/collapse them if enabled. This setting is hidden for UIs that do not support them (which is every UI as of this commit).
2026-05-31 13:57:05 -03:00
RefPtr<Action> m_toggle_vertical_tabs_expanded_action;
LibWebView+UI/Qt: Move the show menu bar setting to LibWebView settings
2026-06-03 16:13:39 -03:00
RefPtr<Action> m_toggle_menu_bar_action;
LibWebView: Integrate bookmarks into the application menus and settings This adds application menus and actions to display and manage bookmarks. These menus will be used by the UIs to generate concrete widgets.
2026-03-22 12:44:54 -03:00
RefPtr<Menu> m_bookmarks_menu;
RefPtr<Action> m_toggle_bookmark_action;
RefPtr<Action> m_toggle_bookmark_bar_action;
size_t m_bookmarks_menu_static_size { 0 };
LibWebView: Add context menu items to interact with the bookmarks bar This adds hooks to add, edit, and delete bookmarks and folders.
2026-03-26 17:55:05 -03:00
RefPtr<Menu> m_bookmarks_bar_context_menu;
RefPtr<Menu> m_bookmark_context_menu;
RefPtr<Menu> m_bookmark_folder_context_menu;
LibWebView+UI: Add a small history application menu This currently just contains a menu item to open about:history. But in the future, we can add a list of recently closed / recently visited pages as well.
2026-06-10 12:54:28 -03:00
RefPtr<Menu> m_history_menu;
LibWebView+UI: Generate the entire Inspect menu Now that all the actions in the Inspect menu are generated, we can generate the menu itself.
2025-09-17 11:22:23 -03:00
RefPtr<Menu> m_inspect_menu;
RefPtr<Action> m_view_source_action;
RefPtr<Action> m_toggle_devtools_action;
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 10:00:52 -03:00
RefPtr<Menu> m_debug_menu;
RefPtr<Action> m_show_line_box_borders_action;
LibWeb: Add a caret hit-test debug overlay Add a debug-menu toggle for caret hit testing at the mouse position. Paint the insertion rect and log the result so selection bugs can be inspected without temporary probes. Request frames and repaint invalidation when the overlay state changes. Also repaint when the caret rect moves within the same text node.
2026-05-30 05:04:28 -03:00
RefPtr<Action> m_show_caret_hit_test_debug_overlay_action;
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 10:00:52 -03:00
RefPtr<Action> m_enable_scripting_action;
LibWeb: Rename ContentFilter to ContentBlocker Rename the local content blocking implementation and its tests from ContentFilter to ContentBlocker while keeping the existing substring matcher backend and behavior. Update the WebContent IPC method, WebView option names, debug toggle, and default config file name to use content blocker terminology.
2026-05-21 11:36:25 -03:00
RefPtr<Action> m_enable_content_blocking_action;
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 10:00:52 -03:00
RefPtr<Action> m_block_pop_ups_action;
StringView m_user_agent_string;
StringView m_navigator_compatibility_mode;
LibWebView: Move headless clipboard management to LibWebView We only supported headless clipboard management in test-web. So when WPT tests the clipboard APIs, we would blindly try to access the Qt app, which does not exist. Note that the AppKit UI has no such restriction, as the NSPasteboard is accessible even without a GUI.
2025-10-10 11:11:56 -03:00
Optional<Web::Clipboard::SystemClipboardRepresentation> m_clipboard;
LibWebView+UI: Add a context menu item to download images This introduces a simple FileDownloader to download files in the UI process from RequestServer. We use this to download the context menu image - this download is likely to hit the disk cache.
2026-02-03 10:00:15 -03:00
FileDownloader m_file_downloader;
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 20:20:46 -03:00
#if defined(AK_OS_MACOS)
Everywhere: Move Mach bootstrap listener into LibIPC Move MachPortServer from LibWebView into LibIPC as MachBootstrapListener and move the Mach message structs from MachMessageTypes.h into LibIPC. These types are IPC infrastructure, not UI or platform concerns. Consolidating them in LibIPC keeps the Mach bootstrap handshake self-contained in a single library and removes LibWebView's dependency on LibThreading.
2026-03-24 03:28:28 -03:00
OwnPtr<IPC::MachBootstrapListener> m_mach_port_server;
Everywhere: Replace Unix socket IPC transport with Mach ports on macOS On macOS, use Mach port messaging instead of Unix domain sockets for all IPC transport. This makes the transport capable of carrying Mach port rights as message attachments, which is a prerequisite for sending IOSurface handles over the main IPC channel (currently sent via a separate out-of-band path). It also avoids the need for the FD acknowledgement protocol that TransportSocket requires, since Mach port right transfers are atomic in the kernel. Three connection establishment patterns: - Spawned helper processes (WebContent, RequestServer, etc.) use the existing MachPortServer: the child sends its task port with a reply port, and the parent responds with a pre-created port pair. - Socket-bootstrapped connections (WebDriver, BrowserProcess) exchange Mach port names over the socket, then drop the socket. - Pre-created pairs for IPC tests and in-message transport transfer. Attachment on macOS now wraps a MachPort instead of a file descriptor, converting between the two via fileport_makeport()/fileport_makefd(). The LibIPC socket transport tests are disabled on macOS since they are socket-specific.
2026-03-19 15:42:05 -03:00
IPC::TransportBootstrapMachServer m_transport_bootstrap_server;
Everywhere: Remove dynamic Mach bootstrap registration on macOS Registering multiple Mach port names with the bootstrap server at runtime is not how macOS expects it to be used — the bootstrap server is meant for static services, and the only reason we used it originally was so child processes could reach back to the UI process. Remove bootstrap_transport_over_socket(), which had both sides register dynamic names with the bootstrap server and exchange them over a socket. Instead, WebDriver and BrowserProcess connections now go through MachPortServer instances directly. When a non-child process contacts a MachPortServer, the server creates a port pair on demand (detected via sysctl ppid check) and returns the local half immediately. This keeps bootstrap server usage limited to the one original case: child processes looking up their parent's MachPortServer. WebDriver Session now runs its own MachPortServer per session. --webdriver-content-path becomes --webdriver-mach-server-name on macOS. Spare WebContent launches are skipped when a WebDriver session is active to avoid bootstrap races.
2026-03-22 15:59:08 -03:00
Function<void(NonnullOwnPtr<IPC::Transport>)> m_on_browser_process_transport;
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 20:20:46 -03:00
#endif
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 10:09:47 -03:00
OwnPtr<DevTools::DevToolsServer> m_devtools;
LibDevTools: Send navigation events to Firefox DevTools When a page navigates, send document-event resources with "will-navigate" and tabNavigated messages so Firefox DevTools can follow along and clear the Network panel appropriately.
2026-01-14 15:03:16 -03:00
mutable HashMap<u64, u64> m_navigation_listener_ids;
Everywhere: Abandon Swift adoption After making no progress on this for a very long time, let's acknowledge it's not going anywhere and remove it from the codebase.
2026-02-17 10:23:39 -03:00
};
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 13:37:05 -03:00
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-30 01:24:01 -03:00
}
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 15:01:05 -03:00
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 20:20:46 -03:00
#define WEB_VIEW_APPLICATION(ApplicationType) \
public: \
template<typename... ApplicationArguments> \
static ErrorOr<NonnullOwnPtr<ApplicationType>> create(Main::Arguments const& arguments, ApplicationArguments&&... application_arguments) \
{ \
auto app = adopt_own(*new ApplicationType { forward<ApplicationArguments>(application_arguments)... }); \
TRY(app->initialize(arguments)); \
return app; \
} \
\
static ApplicationType& the() \
{ \
return static_cast<ApplicationType&>(WebView::Application::the()); \
} \
\
LibWebView: Make WEB_VIEW_APPLICATION switch back to a private section Let's not leave everything after the WEB_VIEW_APPLICATION invocation public.
2025-06-10 20:15:40 -03:00
private:
Reference in a new issue Copy permalink