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

1248 lines
45 KiB
C++
Raw Normal View History

WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 12:31:42 -03:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 08:19:50 -03:00
* Copyright (c) 2020-2021, Andreas Kling <andreas@ladybird.org>
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 12:31:42 -03:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 05:24:48 -03:00
* SPDX-License-Identifier: BSD-2-Clause
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 12:31:42 -03:00
*/
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
#include <AK/Debug.h>
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
#include <AK/JsonArray.h>
#include <AK/JsonObject.h>
#include <AK/NeverDestroyed.h>
#include <AK/WeakPtr.h>
LibWebView: Route wheel bypasses over Compositor IPC Send the experimental UI-process wheel bypass to WebContent over the Compositor IPC connection instead of adding a separate async scrolling transport. This keeps bypass admission on the channel that owns bitmaps and ready_to_paint acknowledgements. If the compositor rejects the wheel, LibWebView falls back to regular input delivery. If it accepts, mark the queued DOM event as having already performed its default action so dispatch preserves ordering without scrolling twice.
2026-05-11 16:45:34 -03:00
#include <LibCore/ElapsedTimer.h>
LibWebView: Fast-close pages without beforeunload prompts Track whether WebContent still needs a beforeunload check and let the frontends immediately remove a tab or window when no prompt can be shown. WebContent still receives the close request so pagehide, unload, and cleanup steps can run. When the visible view is removed immediately, keep detached ownership of the WebContent page until it reports that the top-level traversable closed. If no acknowledgement arrives, release detached ownership and ask ProcessManager to shut down the unused WebContent process.
2026-05-26 13:03:07 -03:00
#include <LibCore/Timer.h>
LibHTTP+Everywhere: Move the cookie implementation to LibHTTP This will allow parsing cookies outside of LibWeb. LibHTTP is basically becoming the home of HTTP WG specs.
2026-02-07 13:13:47 -03:00
#include <LibHTTP/Cookie/ParsedCookie.h>
LibWeb: Present frames through Compositor IPC Introduce a dedicated Compositor IPC channel between the UI process and WebContent. Use it for backing-store setup, presented bitmap delivery, and bitmap-specific ready_to_paint acknowledgements. This makes CompositorThread the single owner of frame presentation bookkeeping before async scrolling starts producing frames without the main thread. Remove old paint and backing-store messages from WebContentClient and PageClient so the UI process no longer observes two presentation protocols.
2026-05-11 16:02:29 -03:00
#include <LibIPC/Transport.h>
LibIPC+LibWeb+LibWebView+Services: Add IPC::TransportHandle Add IPC::TransportHandle as an abstraction for passing IPC transports through .ipc messages. This replaces IPC::File at all sites where a transport (not a generic file) is being transferred between processes. TransportHandle provides from_transport(), clone_from_transport(), and create_transport() methods that encapsulate the fd-to-socket-to-transport conversion in one place. This is preparatory work for Mach port support on macOS -- when that lands, only TransportHandle's internals need to change while all .ipc definitions and call sites remain untouched.
2026-03-11 16:10:08 -03:00
#include <LibIPC/TransportHandle.h>
LibWeb: Handle viewport scrollbar drags in the compositor Route mouse events over the compositor IPC path while async scrolling is enabled, and let the compositor capture viewport scrollbar drags before the main-thread event path sees them. Dragging mutates the compositor scroll tree and schedules an async-scroll present, so the viewport thumb and content can move without a main-thread round trip. Keep normal main-thread event handling for misses and preserve the wheel bypass behavior for page events.
2026-05-12 16:49:42 -03:00
#include <LibWeb/Page/InputEvent.h>
LibWeb+LibWebView+WebContent: Introduce a WebUI framework When we build internal pages (e.g. about:settings), there is currently quite a lot of boilerplate needed to communicate between the browser and the page. This includes creating IDL for the page and the IPC for every message sent between the processes. These internal pages are also special in that they have privileged access to and control over the browser process. The framework introduced here serves to ease the setup of new internal pages and to reduce the access that WebContent processes have to the browser process. WebUI pages can send requests to the browser process via a `ladybird.sendMessage` API. Responses from the browser are passed through a WebUIMessage event. So, for example, an internal page may: ladybird.sendMessage("getDataFor", { id: 123 }); document.addEventListener("WebUIMessage", event => { if (event.name === "gotData") { console.assert(event.data.id === 123); } }); To handle these messages, we set up a new IPC connection between the browser and WebContent processes. This connection is torn down when the user navigates away from the internal page.
2025-03-24 10:27:36 -03:00
#include <LibWebView/Application.h>
LibWebView+WebContent+UI: Remove cookie related WebView callbacks There's no need for each individual chrome to implement the cookie callbacks. We can handle these entirely within LibWebView.
2024-09-22 14:25:18 -03:00
#include <LibWebView/CookieJar.h>
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
#include <LibWebView/HSTSStore.h>
LibWebView+UI: Handle worker agent requests from within LibWebView There is no longer any UI-specific facilities needed to launch a worker agent.
2024-11-13 18:08:08 -03:00
#include <LibWebView/HelperProcess.h>
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
#include <LibWebView/HistoryStore.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 <LibWebView/SourceHighlighter.h>
LibWeb+LibWebView+WebContent: Introduce a WebUI framework When we build internal pages (e.g. about:settings), there is currently quite a lot of boilerplate needed to communicate between the browser and the page. This includes creating IDL for the page and the IPC for every message sent between the processes. These internal pages are also special in that they have privileged access to and control over the browser process. The framework introduced here serves to ease the setup of new internal pages and to reduce the access that WebContent processes have to the browser process. WebUI pages can send requests to the browser process via a `ladybird.sendMessage` API. Responses from the browser are passed through a WebUIMessage event. So, for example, an internal page may: ladybird.sendMessage("getDataFor", { id: 123 }); document.addEventListener("WebUIMessage", event => { if (event.name === "gotData") { console.assert(event.data.id === 123); } }); To handle these messages, we set up a new IPC connection between the browser and WebContent processes. This connection is torn down when the user navigates away from the internal page.
2025-03-24 10:27:36 -03:00
#include <LibWebView/ViewImplementation.h>
#include <LibWebView/WebContentClient.h>
#include <LibWebView/WebUI.h>
LibWebView+WebContent+WebWorker: Move worker ownership into LibWebView This lays the groundwork to allow shared workers, nested workers (i.e. workers owned by workers) and service workers to function independently of WebContent.
2026-05-21 10:33:23 -03:00
#include <LibWebView/WorkerProcessManager.h>
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 12:31:42 -03:00
LibWebView: Move OutOfProcessWebView to a new LibWebView library Also moves WebContentClient and the references to the generated IPC descriptions, since they are all components of OutOfProcessWebView. This patch has no functional changes.
2022-04-30 05:46:33 -03:00
namespace WebView {
LibWeb: Move OutOfProcessWebView into the Web namespace
2020-08-24 08:03:18 -03:00
Meta: Enable exit-time destructor warnings for libraries Enable -Wexit-time-destructors for all in-tree library targets and update process-lifetime library statics so they no longer register exit-time destructors. Long-lived caches, lookup tables, singleton registries, and generated constants now use NeverDestroyed or leaked references where the data is intended to live until process exit. Update LibWeb, LibLine, and the binding generators so regenerated sources follow the same rule instead of reintroducing destructed statics.
2026-06-04 05:40:32 -03:00
HashTable<WebContentClient*>& WebContentClient::clients()
{
static NeverDestroyed<HashTable<WebContentClient*>> clients;
return *clients;
}
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 15:34:51 -03:00
LibWebView: Fast-close pages without beforeunload prompts Track whether WebContent still needs a beforeunload check and let the frontends immediately remove a tab or window when no prompt can be shown. WebContent still receives the close request so pagehide, unload, and cleanup steps can run. When the visible view is removed immediately, keep detached ownership of the WebContent page until it reports that the top-level traversable closed. If no acknowledgement arrives, release detached ownership and ask ProcessManager to shut down the unused WebContent process.
2026-05-26 13:03:07 -03:00
static constexpr auto detached_page_close_timeout_ms = 1000;
static constexpr auto close_server_exit_timeout_ms = 5000;
static constexpr auto detached_page_forced_exit_timeout_ms = detached_page_close_timeout_ms + close_server_exit_timeout_ms;
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
static Optional<String> history_title(Utf16String const& title, URL::URL const& url)
{
if (title.is_empty())
return {};
auto title_utf8 = title.to_utf8();
if (title_utf8 == url.serialize() || title_utf8 == url.serialize(URL::ExcludeFragment::Yes))
return {};
return title_utf8;
}
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
WebContentClient::WebContentClient(NonnullOwnPtr<IPC::Transport> transport, u64 initial_page_id)
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
: IPC::ConnectionToServer<WebContentClientEndpoint, WebContentServerEndpoint>(*this, move(transport))
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
, m_initial_page_id(initial_page_id)
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
{
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
VERIFY(m_initial_page_id > 0);
Meta: Enable exit-time destructor warnings for libraries Enable -Wexit-time-destructors for all in-tree library targets and update process-lifetime library statics so they no longer register exit-time destructors. Long-lived caches, lookup tables, singleton registries, and generated constants now use NeverDestroyed or leaked references where the data is intended to live until process exit. Update LibWeb, LibLine, and the binding generators so regenerated sources follow the same rule instead of reintroducing destructed statics.
2026-06-04 05:40:32 -03:00
clients().set(this);
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
}
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 15:34:51 -03:00
WebContentClient::~WebContentClient()
{
LibWebView+WebContent+WebWorker: Move worker ownership into LibWebView This lays the groundwork to allow shared workers, nested workers (i.e. workers owned by workers) and service workers to function independently of WebContent.
2026-05-21 10:33:23 -03:00
WorkerProcessManager::the().remove_web_content_owner(*this);
Meta: Enable exit-time destructor warnings for libraries Enable -Wexit-time-destructors for all in-tree library targets and update process-lifetime library statics so they no longer register exit-time destructors. Long-lived caches, lookup tables, singleton registries, and generated constants now use NeverDestroyed or leaked references where the data is intended to live until process exit. Update LibWeb, LibLine, and the binding generators so regenerated sources follow the same rule instead of reintroducing destructed statics.
2026-06-04 05:40:32 -03:00
clients().remove(this);
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 15:34:51 -03:00
}
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
Optional<WebContentClient&> WebContentClient::client_for_compositor_context_id(Web::Compositor::CompositorContextId context_id)
{
Optional<WebContentClient&> client;
for_each_client([&](auto& candidate) {
if (!candidate.page_id_for_compositor_context_id(context_id).has_value())
return IterationDecision::Continue;
client = candidate;
return IterationDecision::Break;
});
return client;
}
LibWeb: Handle WebContent process crashes gracefully :^) The OOPWV will now detect WebContent process crashes/disconnections and simply create a new WebContent process in its place. We also generate a little error page with a link to the crashing URL so you can reload and try again. This a huge step forward for OOPWV since it now has a feature that IPWV can never replicate. :^)
2021-01-30 14:20:40 -03:00
void WebContentClient::die()
{
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
// Intentionally empty. Restart is handled at another level.
LibWeb: Handle WebContent process crashes gracefully :^) The OOPWV will now detect WebContent process crashes/disconnections and simply create a new WebContent process in its place. We also generate a little error page with a link to the crashing URL so you can reload and try again. This a huge step forward for OOPWV since it now has a feature that IPWV can never replicate. :^)
2021-01-30 14:20:40 -03:00
}
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
Web::Compositor::CompositorContextId WebContentClient::compositor_context_id_for_page(u64 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
auto context_id = Web::Compositor::compositor_context_id_for_page(page_id);
if (auto registered_page_id = m_compositor_contexts.get(context_id); registered_page_id.has_value()) {
VERIFY(registered_page_id->has_value());
VERIFY(**registered_page_id == page_id);
return context_id;
}
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
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
remember_compositor_context(context_id, page_id);
Application::the().register_compositor_context(*this, context_id, page_id);
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
return context_id;
}
Optional<u64> WebContentClient::page_id_for_compositor_context_id(Web::Compositor::CompositorContextId context_id) const
{
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
auto page_id = m_compositor_contexts.get(context_id);
if (!page_id.has_value())
return {};
return *page_id;
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
}
Messages::WebContentClient::AllocateCompositorContextIdResponse WebContentClient::allocate_compositor_context_id(u64 page_id, Web::Compositor::PagePresentationRegistration page_presentation_registration)
{
if (page_presentation_registration == Web::Compositor::PagePresentationRegistration::Yes)
return compositor_context_id_for_page(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
auto context_id = Application::the().allocate_compositor_context_id();
remember_compositor_context(context_id, {});
Application::the().register_compositor_context(*this, context_id, {});
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
return context_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 WebContentClient::did_destroy_compositor_context(Web::Compositor::CompositorContextId context_id)
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
{
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
forget_compositor_context(context_id);
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
}
bool WebContentClient::forget_compositor_context(Web::Compositor::CompositorContextId context_id)
{
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
if (!m_compositor_contexts.remove(context_id))
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
return false;
return true;
}
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 WebContentClient::remember_compositor_context(Web::Compositor::CompositorContextId context_id, Optional<u64> page_id)
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
{
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
m_compositor_contexts.set(context_id, page_id);
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
}
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 WebContentClient::assign_view(Badge<Application>, ViewImplementation& view)
{
VERIFY(m_views.is_empty());
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
view.m_client_state.page_index = m_initial_page_id;
m_views.set(m_initial_page_id, view);
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
}
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
void WebContentClient::set_compositor_connection_id(Badge<Application>, i32 compositor_connection_id)
{
m_compositor_connection_id = compositor_connection_id;
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::register_view(u64 page_id, ViewImplementation& view)
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 12:31:42 -03:00
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
VERIFY(page_id > 0);
LibWebView: Fast-close pages without beforeunload prompts Track whether WebContent still needs a beforeunload check and let the frontends immediately remove a tab or window when no prompt can be shown. WebContent still receives the close request so pagehide, unload, and cleanup steps can run. When the visible view is removed immediately, keep detached ownership of the WebContent page until it reports that the top-level traversable closed. If no acknowledgement arrives, release detached ownership and ask ProcessManager to shut down the unused WebContent process.
2026-05-26 13:03:07 -03:00
if (m_detached_page_close_timer)
m_detached_page_close_timer->stop();
Application::process_manager().cancel_forced_exit(pid());
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
view.m_client_state.page_index = page_id;
LibWebView: Use NonnullRawPtr for registered views These pointers are always non-null.
2026-01-30 05:08:55 -03:00
m_views.set(page_id, view);
LibWebView: Persist page metadata in history Record visits as soon as a page produces useful metadata such as a title or favicon so pages that never finish loading still become autocomplete candidates. Store favicons in the history schema from the start instead of introducing an upgrade path inside this series, and cover persisted metadata behavior in TestHistoryStore.
2026-04-11 19:33:00 -03:00
m_history_recorded_urls_for_current_load.remove(page_id);
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 12:31:42 -03:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::unregister_view(u64 page_id)
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 13:37:31 -03:00
{
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
forget_compositor_context(Web::Compositor::compositor_context_id_for_page(page_id));
LibWebView: Fast-close pages without beforeunload prompts Track whether WebContent still needs a beforeunload check and let the frontends immediately remove a tab or window when no prompt can be shown. WebContent still receives the close request so pagehide, unload, and cleanup steps can run. When the visible view is removed immediately, keep detached ownership of the WebContent page until it reports that the top-level traversable closed. If no acknowledgement arrives, release detached ownership and ask ProcessManager to shut down the unused WebContent process.
2026-05-26 13:03:07 -03:00
// A page that still needs a beforeunload check is not a detached
// background close. It is being closed without waiting for WebContent,
// e.g. because the user requested a forced close.
if (auto view = m_views.get(page_id); view.has_value() && (*view)->needs_beforeunload_check())
m_detached_pages_pending_close.remove(page_id);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
m_views.remove(page_id);
LibWebView: Persist page metadata in history Record visits as soon as a page produces useful metadata such as a title or favicon so pages that never finish loading still become autocomplete candidates. Store favicons in the history schema from the start instead of introducing an upgrade path inside this series, and cover persisted metadata behavior in TestHistoryStore.
2026-04-11 19:33:00 -03:00
m_history_recorded_urls_for_current_load.remove(page_id);
LibWebView: Fast-close pages without beforeunload prompts Track whether WebContent still needs a beforeunload check and let the frontends immediately remove a tab or window when no prompt can be shown. WebContent still receives the close request so pagehide, unload, and cleanup steps can run. When the visible view is removed immediately, keep detached ownership of the WebContent page until it reports that the top-level traversable closed. If no acknowledgement arrives, release detached ownership and ask ProcessManager to shut down the unused WebContent process.
2026-05-26 13:03:07 -03:00
close_server_if_unused();
}
void WebContentClient::prepare_for_detached_close(u64 page_id)
{
m_detached_pages_pending_close.set(page_id);
}
void WebContentClient::request_close(u64 page_id)
{
// The frontend may destroy the view immediately after this for pages that
// cannot prompt during beforeunload. Keep owning the WebContent close until
// the page reports that its top-level traversable has been closed.
prepare_for_detached_close(page_id);
async_request_close(page_id);
}
void WebContentClient::close_server_if_unused()
{
if (!m_views.is_empty())
return;
if (m_detached_pages_pending_close.is_empty()) {
if (m_detached_page_close_timer)
m_detached_page_close_timer->stop();
WebContent: Add shutdown_server IPC call to request process exit This ensures that removing the last view from a WebContentClient will close its associated process, assuming the WebContent process is not hung. A more drastic measure will be needed to trigger forcefully killing the process when it doesn't respond to this request.
2024-06-30 22:12:22 -03:00
async_close_server();
LibWebView: Fast-close pages without beforeunload prompts Track whether WebContent still needs a beforeunload check and let the frontends immediately remove a tab or window when no prompt can be shown. WebContent still receives the close request so pagehide, unload, and cleanup steps can run. When the visible view is removed immediately, keep detached ownership of the WebContent page until it reports that the top-level traversable closed. If no acknowledgement arrives, release detached ownership and ask ProcessManager to shut down the unused WebContent process.
2026-05-26 13:03:07 -03:00
Application::process_manager().force_exit_after_timeout(pid(), close_server_exit_timeout_ms);
return;
}
Application::process_manager().force_exit_after_timeout(pid(), detached_page_forced_exit_timeout_ms);
if (!m_detached_page_close_timer) {
m_detached_page_close_timer = Core::Timer::create_single_shot(detached_page_close_timeout_ms, [this] {
dbgln("Timed out waiting for detached WebContent page close acknowledgement");
m_detached_pages_pending_close.clear();
close_server_if_unused();
});
}
if (!m_detached_page_close_timer->is_active())
m_detached_page_close_timer->start();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 13:37:31 -03:00
LibWeb+LibWebView+WebContent: Introduce a WebUI framework When we build internal pages (e.g. about:settings), there is currently quite a lot of boilerplate needed to communicate between the browser and the page. This includes creating IDL for the page and the IPC for every message sent between the processes. These internal pages are also special in that they have privileged access to and control over the browser process. The framework introduced here serves to ease the setup of new internal pages and to reduce the access that WebContent processes have to the browser process. WebUI pages can send requests to the browser process via a `ladybird.sendMessage` API. Responses from the browser are passed through a WebUIMessage event. So, for example, an internal page may: ladybird.sendMessage("getDataFor", { id: 123 }); document.addEventListener("WebUIMessage", event => { if (event.name === "gotData") { console.assert(event.data.id === 123); } }); To handle these messages, we set up a new IPC connection between the browser and WebContent processes. This connection is torn down when the user navigates away from the internal page.
2025-03-24 10:27:36 -03:00
void WebContentClient::web_ui_disconnected(Badge<WebUI>)
{
m_web_ui.clear();
}
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
void WebContentClient::destroy_all_compositor_contexts()
{
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
m_compositor_contexts.clear();
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
}
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
ErrorOr<void> WebContentClient::reconnect_to_compositor_process(Badge<Application>)
{
LibWebView+WebContent: Remove compositor thread option Remove the command-line option that allowed Browser to start WebContent with the in-process compositor thread instead of the Compositor helper process. The compositor process is now the default path, so the opt-out flag and the matching WebContent selector only kept the old thread mode reachable. With that option gone, simplify Browser and WebContent startup to wire each WebContent process to the Compositor process directly. The old local Browser-to-WebContent compositor IPC setup and its fallback input and ready-to-paint branches are no longer needed.
2026-05-24 16:51:33 -03:00
if (!is_open())
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
return {};
m_compositor_connection_id.clear();
TRY(Application::the().connect_web_content_to_compositor(*this));
return {};
}
ErrorOr<void> WebContentClient::recreate_compositor_contexts(Badge<Application>)
{
LibWebView+WebContent: Remove compositor thread option Remove the command-line option that allowed Browser to start WebContent with the in-process compositor thread instead of the Compositor helper process. The compositor process is now the default path, so the opt-out flag and the matching WebContent selector only kept the old thread mode reachable. With that option gone, simplify Browser and WebContent startup to wire each WebContent process to the Compositor process directly. The old local Browser-to-WebContent compositor IPC setup and its fallback input and ready-to-paint branches are no longer needed.
2026-05-24 16:51:33 -03:00
if (!is_open())
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
return {};
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
for (auto const& [context_id, page_id] : m_compositor_contexts)
TRY(Application::the().try_register_compositor_context(*this, context_id, page_id));
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
return {};
}
LibWebView+UI: Replay display metadata after Compositor restart Compositor recovery recreated contexts and replayed viewport sizes, but it left the restarted helper with the default display metadata. A recovered context could fall back to a 60 Hz timer instead of the window's current display id and refresh rate until the frontend later observed a screen change. Store the display id in the shared view state, alongside the existing maximum frame rate, and replay both values while restoring view state after reconnect.
2026-05-31 15:16:39 -03:00
void WebContentClient::replay_compositor_view_state_after_reconnect(Badge<Application>)
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
{
LibWebView+WebContent: Remove compositor thread option Remove the command-line option that allowed Browser to start WebContent with the in-process compositor thread instead of the Compositor helper process. The compositor process is now the default path, so the opt-out flag and the matching WebContent selector only kept the old thread mode reachable. With that option gone, simplify Browser and WebContent startup to wire each WebContent process to the Compositor process directly. The old local Browser-to-WebContent compositor IPC setup and its fallback input and ready-to-paint branches are no longer needed.
2026-05-24 16:51:33 -03:00
if (!is_open())
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
return;
for (auto const& [page_id, view] : m_views) {
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
auto context_id = Web::Compositor::compositor_context_id_for_page(page_id);
if (!m_compositor_contexts.contains(context_id))
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
continue;
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
Application::the().update_compositor_viewport(context_id, view->viewport_size().to_type<int>());
LibWebView+UI: Replay display metadata after Compositor restart Compositor recovery recreated contexts and replayed viewport sizes, but it left the restarted helper with the default display metadata. A recovered context could fall back to a 60 Hz timer instead of the window's current display id and refresh rate until the frontend later observed a screen change. Store the display id in the shared view state, alongside the existing maximum frame rate, and replay both values while restoring view state after reconnect.
2026-05-31 15:16:39 -03:00
Application::the().update_compositor_display_metadata(context_id, view->display_id(), view->maximum_frames_per_second());
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 WebContentClient::notify_compositor_process_reconnected(Badge<Application>)
{
LibWebView+WebContent: Remove compositor thread option Remove the command-line option that allowed Browser to start WebContent with the in-process compositor thread instead of the Compositor helper process. The compositor process is now the default path, so the opt-out flag and the matching WebContent selector only kept the old thread mode reachable. With that option gone, simplify Browser and WebContent startup to wire each WebContent process to the Compositor process directly. The old local Browser-to-WebContent compositor IPC setup and its fallback input and ready-to-paint branches are no longer needed.
2026-05-24 16:51:33 -03:00
if (!is_open())
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
return;
async_compositor_process_reconnected();
}
LibWebView: Notify all views when shared WebContent crashes When multiple views share a WebContent process (e.g. parent and child views created via window.open()), we need to notify ALL of them when the process crashes, not just one. Previously, each view would overwrite the single crash callback on WebContentClient, so only the last view to initialize would be notified. This adds WebContentClient::notify_all_views_of_crash() which iterates over all registered views and notifies each one. Child views also now propagate crashes to their parent, and can be disconnected between tests to prevent stale crashes from affecting subsequent tests.
2026-01-13 19:32:16 -03:00
void WebContentClient::notify_all_views_of_crash()
{
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
destroy_all_compositor_contexts();
LibWebView: Notify all views when shared WebContent crashes When multiple views share a WebContent process (e.g. parent and child views created via window.open()), we need to notify ALL of them when the process crashes, not just one. Previously, each view would overwrite the single crash callback on WebContentClient, so only the last view to initialize would be notified. This adds WebContentClient::notify_all_views_of_crash() which iterates over all registered views and notifies each one. Child views also now propagate crashes to their parent, and can be disconnected between tests to prevent stale crashes from affecting subsequent tests.
2026-01-13 19:32:16 -03:00
// Collect view IDs first, then use deferred_invoke to handle crashes safely
// (avoids signal handler deadlock and allows views to be looked up by ID
// in case they're destroyed before the deferred_invoke runs).
Vector<u64> view_ids;
view_ids.ensure_capacity(m_views.size());
for (auto& [page_id, view] : m_views)
LibWebView: Use ::unchecked_append() for view IDs
2026-01-30 05:08:37 -03:00
view_ids.unchecked_append(view->view_id());
LibWebView: Notify all views when shared WebContent crashes When multiple views share a WebContent process (e.g. parent and child views created via window.open()), we need to notify ALL of them when the process crashes, not just one. Previously, each view would overwrite the single crash callback on WebContentClient, so only the last view to initialize would be notified. This adds WebContentClient::notify_all_views_of_crash() which iterates over all registered views and notifies each one. Child views also now propagate crashes to their parent, and can be disconnected between tests to prevent stale crashes from affecting subsequent tests.
2026-01-13 19:32:16 -03:00
for (auto view_id : view_ids) {
Core::deferred_invoke([view_id] {
auto view = ViewImplementation::find_view_by_id(view_id);
if (!view.has_value())
return;
view->handle_web_content_process_crash();
if (view->on_web_content_crashed)
view->on_web_content_crashed();
});
}
}
LibWeb+LibWebView: Feed async scroll deltas in device pixels The synchronous wheel path treats wheel deltas as CSS-pixel scroll distances, while the async compositor scroll tree mutates scroll state stored in device pixels. Passing the same unscaled delta into the compositor made async scrolling advance too little whenever device pixels per CSSPixel was greater than 1, so scrolling felt slower than with async scrolling disabled. Convert wheel deltas before crossing the compositor boundary and make the compositor IPC carry only the device-pixel position and delta it needs. This keeps AsyncScrollTree device-pixel native and makes async viewport scrolling match the synchronous path across high-DPI displays and page zoom levels.
2026-05-12 14:38:29 -03:00
bool WebContentClient::send_async_scroll_to_compositor(u64 page_id, Gfx::FloatPoint position, Gfx::FloatPoint delta_in_device_pixels)
LibWebView: Route wheel bypasses over Compositor IPC Send the experimental UI-process wheel bypass to WebContent over the Compositor IPC connection instead of adding a separate async scrolling transport. This keeps bypass admission on the channel that owns bitmaps and ready_to_paint acknowledgements. If the compositor rejects the wheel, LibWebView falls back to regular input delivery. If it accepts, mark the queued DOM event as having already performed its default action so dispatch preserves ordering without scrolling twice.
2026-05-11 16:45:34 -03:00
{
auto timer = Core::ElapsedTimer::start_new(Core::TimerType::Precise);
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+WebContent: Remove compositor thread option Remove the command-line option that allowed Browser to start WebContent with the in-process compositor thread instead of the Compositor helper process. The compositor process is now the default path, so the opt-out flag and the matching WebContent selector only kept the old thread mode reachable. With that option gone, simplify Browser and WebContent startup to wire each WebContent process to the Compositor process directly. The old local Browser-to-WebContent compositor IPC setup and its fallback input and ready-to-paint branches are no longer needed.
2026-05-24 16:51:33 -03:00
auto handled = Application::the().send_async_scroll_to_compositor(compositor_context_id_for_page(page_id), position, delta_in_device_pixels);
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
LibWeb+LibWebView: Feed async scroll deltas in device pixels The synchronous wheel path treats wheel deltas as CSS-pixel scroll distances, while the async compositor scroll tree mutates scroll state stored in device pixels. Passing the same unscaled delta into the compositor made async scrolling advance too little whenever device pixels per CSSPixel was greater than 1, so scrolling felt slower than with async scrolling disabled. Convert wheel deltas before crossing the compositor boundary and make the compositor IPC carry only the device-pixel position and delta it needs. This keeps AsyncScrollTree device-pixel native and makes async viewport scrolling match the synchronous path across high-DPI displays and page zoom levels.
2026-05-12 14:38:29 -03:00
dbgln_if(COMPOSITOR_DEBUG, "[Compositor] UI compositor IPC async_scroll_by page {} returned {} in {} us",
LibWebView: Route wheel bypasses over Compositor IPC Send the experimental UI-process wheel bypass to WebContent over the Compositor IPC connection instead of adding a separate async scrolling transport. This keeps bypass admission on the channel that owns bitmaps and ready_to_paint acknowledgements. If the compositor rejects the wheel, LibWebView falls back to regular input delivery. If it accepts, mark the queued DOM event as having already performed its default action so dispatch preserves ordering without scrolling twice.
2026-05-11 16:45:34 -03:00
page_id, handled, timer.elapsed_time().to_microseconds());
return handled;
}
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 WebContentClient::handle_mouse_event_in_compositor(u64 page_id, Web::MouseEvent const& event)
LibWeb: Handle viewport scrollbar drags in the compositor Route mouse events over the compositor IPC path while async scrolling is enabled, and let the compositor capture viewport scrollbar drags before the main-thread event path sees them. Dragging mutates the compositor scroll tree and schedules an async-scroll present, so the viewport thumb and content can move without a main-thread round trip. Keep normal main-thread event handling for misses and preserve the wheel bypass behavior for page events.
2026-05-12 16:49:42 -03:00
{
auto timer = Core::ElapsedTimer::start_new(Core::TimerType::Precise);
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+WebContent: Remove compositor thread option Remove the command-line option that allowed Browser to start WebContent with the in-process compositor thread instead of the Compositor helper process. The compositor process is now the default path, so the opt-out flag and the matching WebContent selector only kept the old thread mode reachable. With that option gone, simplify Browser and WebContent startup to wire each WebContent process to the Compositor process directly. The old local Browser-to-WebContent compositor IPC setup and its fallback input and ready-to-paint branches are no longer needed.
2026-05-24 16:51:33 -03:00
auto handled = Application::the().handle_mouse_event_in_compositor(compositor_context_id_for_page(page_id), event);
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
LibWeb: Handle viewport scrollbar drags in the compositor Route mouse events over the compositor IPC path while async scrolling is enabled, and let the compositor capture viewport scrollbar drags before the main-thread event path sees them. Dragging mutates the compositor scroll tree and schedules an async-scroll present, so the viewport thumb and content can move without a main-thread round trip. Keep normal main-thread event handling for misses and preserve the wheel bypass behavior for page events.
2026-05-12 16:49:42 -03:00
dbgln_if(COMPOSITOR_DEBUG, "[Compositor] UI compositor IPC mouse_event page {} returned {} in {} us",
page_id, handled, timer.elapsed_time().to_microseconds());
return handled;
}
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 WebContentClient::dispatch_mouse_event_to_web_content(u64 page_id, Web::MouseEvent const& event)
{
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
auto context_id = compositor_context_id_for_page(page_id);
if (Application::the().dispatch_mouse_event_to_web_content(context_id, event))
LibWebView+WebContent: Remove compositor thread option Remove the command-line option that allowed Browser to start WebContent with the in-process compositor thread instead of the Compositor helper process. The compositor process is now the default path, so the opt-out flag and the matching WebContent selector only kept the old thread mode reachable. With that option gone, simplify Browser and WebContent startup to wire each WebContent process to the Compositor process directly. The old local Browser-to-WebContent compositor IPC setup and its fallback input and ready-to-paint branches are no longer needed.
2026-05-24 16:51:33 -03:00
return;
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
async_mouse_event(page_id, event.clone_without_browser_data());
}
LibWeb: Present frames through Compositor IPC Introduce a dedicated Compositor IPC channel between the UI process and WebContent. Use it for backing-store setup, presented bitmap delivery, and bitmap-specific ready_to_paint acknowledgements. This makes CompositorThread the single owner of frame presentation bookkeeping before async scrolling starts producing frames without the main thread. Remove old paint and backing-store messages from WebContentClient and PageClient so the UI process no longer observes two presentation protocols.
2026-05-11 16:02:29 -03:00
void WebContentClient::notify_presented_bitmap_ready_to_paint(u64 page_id, i32 bitmap_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
auto context_id = Web::Compositor::compositor_context_id_for_page(page_id);
if (!m_compositor_contexts.contains(context_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
return;
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
Application::the().notify_compositor_presented_bitmap_ready_to_paint(context_id, bitmap_id);
LibWeb: Present frames through Compositor IPC Introduce a dedicated Compositor IPC channel between the UI process and WebContent. Use it for backing-store setup, presented bitmap delivery, and bitmap-specific ready_to_paint acknowledgements. This makes CompositorThread the single owner of frame presentation bookkeeping before async scrolling starts producing frames without the main thread. Remove old paint and backing-store messages from WebContentClient and PageClient so the UI process no longer observes two presentation protocols.
2026-05-11 16:02:29 -03:00
}
void WebContentClient::did_present_bitmap(u64 page_id, Gfx::IntRect rect, i32 bitmap_id)
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
{
LibWeb: Add compositor debug logging Trace the compositor state transitions that matter once presentation and async scrolling share one path: page registration, backing-store swaps, did_paint delivery, ready_to_paint acknowledgements, wheel admission, and deferred presents waiting for reusable bitmaps. Keep the logs under COMPOSITOR_DEBUG and use the [Compositor] prefix consistently. The trace is about ownership and backpressure instead of dumping every wheel event detail, so stalls can be diagnosed without reintroducing noisy async-scrolling-only logging.
2026-05-11 16:48:43 -03:00
dbgln_if(COMPOSITOR_DEBUG, "[Compositor] UI compositor IPC did_paint for page {} bitmap {} rect={}x{} at {},{}",
page_id, bitmap_id, rect.width(), rect.height(), rect.x(), rect.y());
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
view->server_did_paint({}, bitmap_id, rect.size());
LibWeb: Present frames through Compositor IPC Introduce a dedicated Compositor IPC channel between the UI process and WebContent. Use it for backing-store setup, presented bitmap delivery, and bitmap-specific ready_to_paint acknowledgements. This makes CompositorThread the single owner of frame presentation bookkeeping before async scrolling starts producing frames without the main thread. Remove old paint and backing-store messages from WebContentClient and PageClient so the UI process no longer observes two presentation protocols.
2026-05-11 16:02:29 -03:00
} else {
dbgln_if(COMPOSITOR_DEBUG, "[Compositor] UI dropping did_paint for page {} bitmap {}: no view",
page_id, bitmap_id);
LibWebView+WebContent: Remove compositor thread option Remove the command-line option that allowed Browser to start WebContent with the in-process compositor thread instead of the Compositor helper process. The compositor process is now the default path, so the opt-out flag and the matching WebContent selector only kept the old thread mode reachable. With that option gone, simplify Browser and WebContent startup to wire each WebContent process to the Compositor process directly. The old local Browser-to-WebContent compositor IPC setup and its fallback input and ready-to-paint branches are no longer needed.
2026-05-24 16:51:33 -03:00
notify_presented_bitmap_ready_to_paint(page_id, bitmap_id);
LibWeb: Present frames through Compositor IPC Introduce a dedicated Compositor IPC channel between the UI process and WebContent. Use it for backing-store setup, presented bitmap delivery, and bitmap-specific ready_to_paint acknowledgements. This makes CompositorThread the single owner of frame presentation bookkeeping before async scrolling starts producing frames without the main thread. Remove old paint and backing-store messages from WebContentClient and PageClient so the UI process no longer observes two presentation protocols.
2026-05-11 16:02:29 -03:00
}
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 13:37:31 -03:00
}
LibWeb+LibWebView+WebContent: Begin implementing simple site islotation Site isolation is a common technique to reduce the chance that malicious sites can access data from other sites. When the user navigates, we now check if the target site is the same as the current site. If not, we instruct the UI to perform the navigation in a new WebContent process. The phrase "site" here is defined as the public suffix of the URL plus one level. This means that navigating from "www.example.com" to "sub.example.com" remains in the same process. There's plenty of room for optimization around this. For example, we can create a spare WebContent process ahead of time to hot-swap the target site. We can also create a policy to keep the navigated-from process around, in case the user quickly navigates back.
2025-03-09 12:40:34 -03:00
void WebContentClient::did_request_new_process_for_navigation(u64 page_id, URL::URL url)
{
if (auto view = view_for_page_id(page_id); view.has_value())
view->create_new_process_for_cross_site_navigation(url);
}
LibWebView: Persist page metadata in history Record visits as soon as a page produces useful metadata such as a title or favicon so pages that never finish loading still become autocomplete candidates. Store favicons in the history schema from the start instead of introducing an upgrade path inside this series, and cover persisted metadata behavior in TestHistoryStore.
2026-04-11 19:33:00 -03:00
void WebContentClient::maybe_record_history_visit_for_current_load(u64 page_id, URL::URL const& url, Optional<String> title, StringView reason)
{
auto normalized_url = HistoryStore::normalize_url(url);
if (!normalized_url.has_value())
return;
if (auto recorded_url = m_history_recorded_urls_for_current_load.get(page_id); recorded_url.has_value() && *recorded_url == *normalized_url) {
dbgln_if(WEBVIEW_HISTORY_DEBUG, "[History] Visit for page {} at '{}' was already recorded during this load before {}", page_id, *normalized_url, reason);
return;
}
dbgln_if(WEBVIEW_HISTORY_DEBUG, "[History] Recording history visit for page {} at '{}' after {}", page_id, *normalized_url, reason);
// Title and favicon updates already give us a useful history entry, so
// do not wait for did_finish_loading() on pages that never reach it.
Application::history_store().record_visit(url, move(title));
m_history_recorded_urls_for_current_load.set(page_id, normalized_url.release_value());
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_start_loading(u64 page_id, URL::URL url, bool is_redirect)
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 12:31:42 -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
if (auto process = WebView::Application::the().find_process(m_process_handle.pid); process.has_value())
process->set_title(OptionalNone {});
LibWebView: Display each tab's title in the Task Manager This allows us to more easily differentiate between WebContent processes in the Task Manager at a glance.
2024-04-22 15:11:46 -03:00
LibWebView: Persist page metadata in history Record visits as soon as a page produces useful metadata such as a title or favicon so pages that never finish loading still become autocomplete candidates. Store favicons in the history schema from the start instead of introducing an upgrade path inside this series, and cover persisted metadata behavior in TestHistoryStore.
2026-04-11 19:33:00 -03:00
m_history_recorded_urls_for_current_load.remove(page_id);
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWeb+LibWebView: Preserve crashed page URLs on crash Load the browser-generated crash page as a synthetic response for the URL that was active when WebContent exited. This keeps the session history entry, response URL, and created Document aligned with the same navigation URL, so reload targets the original page without creating a local document for an HTTP(S) history entry. Suppress history metadata updates from the generated page and declare an inert rel=icon. Fallback favicon loading now follows the HTML condition that no link with the icon keyword exists, which avoids the credentialed /favicon.ico request from the crashed origin.
2026-05-20 11:42:08 -03:00
view->m_should_suppress_history_for_current_load = view->m_should_suppress_history_for_next_load;
view->m_should_suppress_history_for_next_load = false;
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
view->set_url({}, url);
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 13:37:31 -03:00
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (view->on_load_start)
view->on_load_start(url, is_redirect);
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
for (auto const& [id, listener] : view->m_navigation_listeners) {
if (listener.on_load_start)
listener.on_load_start(url, is_redirect);
}
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
}
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 12:31:42 -03:00
}
WebContent: Allow the WebContent process to trigger repaints After layout, we may want to repaint the page, so we now listen for the PageClient::page_did_invalidate() notification and use it to drive a client-side repaint. Note that an invalidation request from LibWeb makes a full roundtrip to the WebContent client and back since the client drives painting.
2020-06-17 13:00:18 -03:00
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_finish_loading(u64 page_id, URL::URL url)
LibWeb+WebContent+headless-browser: Support async text tests Previously, we used `on_load_finish` to determine when the text test was completed. This method did not allow testing of async functions because there was no way to indicate that the runner should wait for the async call to end. This change introduces a function in the `internals` object that is intended to be called when the text test execution is completed. The text test runner will now ignore `on_load_finish` which means a test will timeout if this new function is never called. `test(f)` function in `include.js` has been modified to automatically terminate a test once `load` event is fired on `window`. new `asyncTest(f)` function has been introduces. `f` receives function that will terminate a test as a first argument. Every test is expected to call either `test()` or `asyncTest()` to complete. If not, it will remain hanging until a timeout occurs.
2023-09-14 14:17:32 -03:00
{
LibWeb+LibWebView+WebContent: Introduce a WebUI framework When we build internal pages (e.g. about:settings), there is currently quite a lot of boilerplate needed to communicate between the browser and the page. This includes creating IDL for the page and the IPC for every message sent between the processes. These internal pages are also special in that they have privileged access to and control over the browser process. The framework introduced here serves to ease the setup of new internal pages and to reduce the access that WebContent processes have to the browser process. WebUI pages can send requests to the browser process via a `ladybird.sendMessage` API. Responses from the browser are passed through a WebUIMessage event. So, for example, an internal page may: ladybird.sendMessage("getDataFor", { id: 123 }); document.addEventListener("WebUIMessage", event => { if (event.name === "gotData") { console.assert(event.data.id === 123); } }); To handle these messages, we set up a new IPC connection between the browser and WebContent processes. This connection is torn down when the user navigates away from the internal page.
2025-03-24 10:27:36 -03:00
if (url.scheme() == "about"sv && url.paths().size() == 1) {
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
if (auto web_ui = WebUI::create(*this, page_id, url.paths().first()); web_ui.is_error())
LibWeb+LibWebView+WebContent: Introduce a WebUI framework When we build internal pages (e.g. about:settings), there is currently quite a lot of boilerplate needed to communicate between the browser and the page. This includes creating IDL for the page and the IPC for every message sent between the processes. These internal pages are also special in that they have privileged access to and control over the browser process. The framework introduced here serves to ease the setup of new internal pages and to reduce the access that WebContent processes have to the browser process. WebUI pages can send requests to the browser process via a `ladybird.sendMessage` API. Responses from the browser are passed through a WebUIMessage event. So, for example, an internal page may: ladybird.sendMessage("getDataFor", { id: 123 }); document.addEventListener("WebUIMessage", event => { if (event.name === "gotData") { console.assert(event.data.id === 123); } }); To handle these messages, we set up a new IPC connection between the browser and WebContent processes. This connection is torn down when the user navigates away from the internal page.
2025-03-24 10:27:36 -03:00
warnln("Could not create WebUI for {}: {}", url, web_ui.error());
else
m_web_ui = web_ui.release_value();
}
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWeb+LibWebView: Preserve crashed page URLs on crash Load the browser-generated crash page as a synthetic response for the URL that was active when WebContent exited. This keeps the session history entry, response URL, and created Document aligned with the same navigation URL, so reload targets the original page without creating a local document for an HTTP(S) history entry. Suppress history metadata updates from the generated page and declare an inert rel=icon. Fallback favicon loading now follows the HTML condition that no link with the icon keyword exists, which avoids the credentialed /favicon.ico request from the crashed origin.
2026-05-20 11:42:08 -03:00
auto client_url = url;
// Browser-generated pages can finish with an internal document URL.
// Keep exposing the URL accepted at load start for suppressed loads.
if (view->m_should_suppress_history_for_current_load)
client_url = view->url();
else
view->set_url({}, url);
auto should_update_history = !view->m_should_suppress_history_for_current_load;
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
auto title = history_title(view->title(), url);
LibWeb+LibWebView: Preserve crashed page URLs on crash Load the browser-generated crash page as a synthetic response for the URL that was active when WebContent exited. This keeps the session history entry, response URL, and created Document aligned with the same navigation URL, so reload targets the original page without creating a local document for an HTTP(S) history entry. Suppress history metadata updates from the generated page and declare an inert rel=icon. Fallback favicon loading now follows the HTML condition that no link with the icon keyword exists, which avoids the credentialed /favicon.ico request from the crashed origin.
2026-05-20 11:42:08 -03:00
if (should_update_history) {
dbgln_if(WEBVIEW_HISTORY_DEBUG, "[History] Load finished for page {} at '{}' with title '{}'",
page_id,
url,
title.has_value() ? title->bytes_as_string_view() : "<none>"sv);
maybe_record_history_visit_for_current_load(page_id, url, title, "load finish"sv);
if (title.has_value())
Application::history_store().update_title(url, *title);
if (view->favicon_base64_png().has_value())
Application::history_store().update_favicon(url, *view->favicon_base64_png());
}
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (view->on_load_finish)
LibWeb+LibWebView: Preserve crashed page URLs on crash Load the browser-generated crash page as a synthetic response for the URL that was active when WebContent exited. This keeps the session history entry, response URL, and created Document aligned with the same navigation URL, so reload targets the original page without creating a local document for an HTTP(S) history entry. Suppress history metadata updates from the generated page and declare an inert rel=icon. Fallback favicon loading now follows the HTML condition that no link with the icon keyword exists, which avoids the credentialed /favicon.ico request from the crashed origin.
2026-05-20 11:42:08 -03:00
view->on_load_finish(client_url);
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
for (auto const& [id, listener] : view->m_navigation_listeners) {
if (listener.on_load_finish)
LibWeb+LibWebView: Preserve crashed page URLs on crash Load the browser-generated crash page as a synthetic response for the URL that was active when WebContent exited. This keeps the session history entry, response URL, and created Document aligned with the same navigation URL, so reload targets the original page without creating a local document for an HTTP(S) history entry. Suppress history metadata updates from the generated page and declare an inert rel=icon. Fallback favicon loading now follows the HTML condition that no link with the icon keyword exists, which avoids the credentialed /favicon.ico request from the crashed origin.
2026-05-20 11:42:08 -03:00
listener.on_load_finish(client_url);
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
}
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
}
LibWeb+WebContent+headless-browser: Support async text tests Previously, we used `on_load_finish` to determine when the text test was completed. This method did not allow testing of async functions because there was no way to indicate that the runner should wait for the async call to end. This change introduces a function in the `internals` object that is intended to be called when the text test execution is completed. The text test runner will now ignore `on_load_finish` which means a test will timeout if this new function is never called. `test(f)` function in `include.js` has been modified to automatically terminate a test once `load` event is fired on `window`. new `asyncTest(f)` function has been introduces. `f` receives function that will terminate a test as a first argument. Every test is expected to call either `test()` or `asyncTest()` to complete. If not, it will remain hanging until a timeout occurs.
2023-09-14 14:17:32 -03:00
}
LibWeb: Rename internals.signalTextTestIsDone() to signalTestIsDone() In upcoming change this function will be used for ref-tests as well.
2025-03-18 13:37:32 -03:00
void WebContentClient::did_finish_test(u64 page_id, String text)
LibWebView+WebContent: Add IPCs to navigate the browser's history
2022-11-11 15:33:11 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWeb: Rename internals.signalTextTestIsDone() to signalTestIsDone() In upcoming change this function will be used for ref-tests as well.
2025-03-18 13:37:32 -03:00
if (view->on_test_finish)
view->on_test_finish(text);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
}
headless-browser: Let tests set their own timeout duration Some tests take longer than others, and so may want to set a custom timeout so that they pass, without increasing the timeout for all other tests. For example, this is done in WPT. Add an `internals.setTestTimeout(milliseconds)` method that overrides the test runner's default timeout for the currently-run test.
2024-12-19 11:16:05 -03:00
void WebContentClient::did_set_test_timeout(u64 page_id, double milliseconds)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_set_test_timeout)
view->on_set_test_timeout(milliseconds);
}
}
Tests: Replace `load-reference-page` debug action with internals method WPT reference tests can add metadata to tests to instruct the test runner how to interpret the results. Because of this, it is not enough to have an action that starts loading the (mis)match reference: we need the test runner to receive the metadata so it can act accordingly. This sets our test runner up for potentially supporting multiple (mis)match references, and fuzzy rendering matches - the latter will be implemented in the following commit.
2025-07-16 05:24:15 -03:00
void WebContentClient::did_receive_reference_test_metadata(u64 page_id, JsonValue metadata)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_reference_test_metadata)
view->on_reference_test_metadata(metadata);
}
}
Tests/LibWeb: Support WPT variant meta tags in test-web Add support for WPT test variants, which allow a single test file to be run multiple times with different URL query parameters. Tests declare variants using `<meta name="variant" content="?param=value">` tags. When test-web encounters a test with variants, it expands that test into multiple runs, each with its own expectation file using the naming convention `testname@variant.txt` (e.g., `test@run_type=uri.txt`). Implementation details: - WebContent observes variant meta tags and communicates them to the test runner via a new `did_receive_test_variant_metadata` IPC call - test-web dynamically expands tests with variants during execution, waking idle views after each test completion to pick up new work - Use index-based test tracking to avoid dangling references when the test vector grows during variant expansion - Introduce TestRunContext to group test run state, and store a static pointer to it for signal handler access This enables proper testing of WPT tests that use variants, such as the html5lib parsing tests (which test uri, write, and write_single modes) and the editing/bold tests (which split across multiple ranges).
2026-01-13 13:33:48 -03:00
void WebContentClient::did_receive_test_variant_metadata(u64 page_id, JsonValue metadata)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_test_variant_metadata)
view->on_test_variant_metadata(metadata);
}
}
LibWeb+UI: Add internals API to set browser zoom
2024-12-23 18:15:06 -03:00
void WebContentClient::did_set_browser_zoom(u64 page_id, double factor)
{
LibWebView+UI: Generate the zoom menu
2025-09-10 08:23:15 -03:00
if (auto view = view_for_page_id(page_id); view.has_value())
view->set_zoom(factor);
LibWeb+UI: Add internals API to set browser zoom
2024-12-23 18:15:06 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_find_in_page(u64 page_id, size_t current_match_index, Optional<size_t> total_match_count)
LibWeb+WebContent: Provide feedback on find in page requests This change allows the results of a find in page query to be reported back to the user interface. Currently, the number of results found and the current match index are reported.
2024-06-09 14:35:32 -03:00
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_find_in_page)
view->on_find_in_page(current_match_index, total_match_count);
}
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_request_refresh(u64 page_id)
LibWebView+WebContent: Add IPCs to navigate the browser's history
2022-11-11 15:33:11 -03:00
{
LibWebView+UI: Remove history traversal WebView callbacks We can handle these entirely within LibWebView.
2024-09-22 14:29:27 -03:00
if (auto view = view_for_page_id(page_id); view.has_value())
view->reload();
LibWebView+WebContent: Add IPCs to navigate the browser's history
2022-11-11 15:33:11 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_cursor_change(u64 page_id, Gfx::Cursor cursor)
LibWeb: Support setting the cursor in OutOfProcessWebView
2021-02-27 18:12:12 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_cursor_change)
LibWeb+WebContent+UI: Support image cursors The `cursor` property accepts a list of possible cursors, which behave as a fallback: We use whichever cursor is the first available one. This is a little complicated because initially, any remote images have not loaded, so we need to use the fallback standard cursor, and then switch to another when it loads. So, ComputedValues stores a Vector of cursors, and then in EventHandler we scan down that list until we find a cursor that's ready for use. The spec defines cursors as being `<url>`, but allows for `<image>` instead. That includes functions like `linear-gradient()`. This commit implements image cursors in the Qt UI, but not AppKit.
2025-02-20 09:17:29 -03:00
view->on_cursor_change(cursor);
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
}
LibWeb: Support setting the cursor in OutOfProcessWebView
2021-02-27 18:12:12 -03:00
}
LibWeb+LibWebView+WebContent+UI: Port the document title to UTF-16
2025-07-28 17:51:01 -03:00
void WebContentClient::did_change_title(u64 page_id, Utf16String title)
WebContent: Plumb title changes over to the WebContentView WebContentView now fires its on_title_change hook, like Web::PageView. We use this in the WebView test app to update the window title. :^)
2020-07-04 18:40:17 -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
if (auto process = WebView::Application::the().find_process(m_process_handle.pid); process.has_value())
LibWeb+LibWebView+WebContent+UI: Port the document title to UTF-16
2025-07-28 17:51:01 -03:00
process->set_title(title);
LibWebView: Display each tab's title in the Task Manager This allows us to more easily differentiate between WebContent processes in the Task Manager at a glance.
2024-04-22 15:11:46 -03:00
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWeb+LibWebView: Preserve crashed page URLs on crash Load the browser-generated crash page as a synthetic response for the URL that was active when WebContent exited. This keeps the session history entry, response URL, and created Document aligned with the same navigation URL, so reload targets the original page without creating a local document for an HTTP(S) history entry. Suppress history metadata updates from the generated page and declare an inert rel=icon. Fallback favicon loading now follows the HTML condition that no link with the icon keyword exists, which avoids the credentialed /favicon.ico request from the crashed origin.
2026-05-20 11:42:08 -03:00
if (!title.is_empty() && !view->m_should_suppress_history_for_current_load) {
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
auto title_utf8 = title.to_utf8();
LibWebView: Persist page metadata in history Record visits as soon as a page produces useful metadata such as a title or favicon so pages that never finish loading still become autocomplete candidates. Store favicons in the history schema from the start instead of introducing an upgrade path inside this series, and cover persisted metadata behavior in TestHistoryStore.
2026-04-11 19:33:00 -03:00
maybe_record_history_visit_for_current_load(page_id, view->url(), title_utf8, "title change"sv);
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
dbgln_if(WEBVIEW_HISTORY_DEBUG, "[History] Title changed for page {} at '{}' to '{}'",
page_id,
view->url(),
title_utf8);
Application::history_store().update_title(view->url(), title_utf8);
}
LibWeb+LibWebView+WebContent+UI: Port the document title to UTF-16
2025-07-28 17:51:01 -03:00
if (title.is_empty())
title = Utf16String::from_utf8(view->url().serialize());
view->set_title({}, title);
Browser+Ladybird+LibWebView: Consolidate title handling in LibWebView Namely, let's have empty titles behave the same in both Browser and Ladybird (display the URL).
2023-06-07 17:37:30 -03:00
LibWebView: Store the tab title on the ViewImplementation This will be needed for DevTools, to avoid the need to go into the UI layer for this information.
2025-02-17 08:43:06 -03:00
if (view->on_title_change)
LibWeb+LibWebView+WebContent+UI: Port the document title to UTF-16
2025-07-28 17:51:01 -03:00
view->on_title_change(title);
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
}
WebContent: Plumb title changes over to the WebContentView WebContentView now fires its on_title_change hook, like Web::PageView. We use this in the WebView test app to update the window title. :^)
2020-07-04 18:40:17 -03:00
}
WebContent: Plumb scroll-into-view requests from server to client The WebContentView widget will now be able to react to scroll-into-view requests from the WebContent process.
2020-07-05 10:43:43 -03:00
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_change_url(u64 page_id, URL::URL url)
LibWeb+LibWebView+WebContent: Add did_change_url() IPC call
2024-04-14 05:27:20 -03:00
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWebView: Ignore duplicate URL change notifications Some navigations report the same URL more than once through WebContentClient::did_change_url(). Forwarding those duplicate updates into the frontend turned an internal no-op into visible UI churn, including location bar resets and AppKit focus stealing. Treat repeated URL notifications as a no-op inside LibWebView so frontends only react to real URL changes.
2026-04-11 20:38:54 -03:00
// Some navigations report the same URL more than once. Keep those
// duplicate updates inside LibWebView so frontends do not reset
// location bar state or steal focus for a no-op change.
if (view->url() == url)
return;
LibWebView: Update the stored URL when WebContent's URL changes
2024-04-14 17:59:59 -03:00
view->set_url({}, url);
LibWeb+LibWebView+WebContent: Add did_change_url() IPC call
2024-04-14 05:27:20 -03:00
if (view->on_url_change)
view->on_url_change(url);
}
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_tooltip_override(u64 page_id, Gfx::IntPoint position, ByteString title)
LibWeb+UI: Add tooltip overriding and use it for <video> tags This call is used to inform the chrome that it should display a tooltip now and avoid any hovering timers. This is used by <video> tags to display the volume percentage when it is changed.
2024-07-02 11:48:57 -03:00
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_tooltip_override)
view->on_request_tooltip_override(view->to_widget_position(position), title);
}
}
void WebContentClient::did_stop_tooltip_override(u64 page_id)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_stop_tooltip_override)
view->on_stop_tooltip_override();
}
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_enter_tooltip_area(u64 page_id, ByteString title)
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 13:10:06 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_enter_tooltip_area)
LibWeb+UI/Qt: Display 'title' tooltips only when the mouse stops moving Now instead of sending the position in which the user entered the tooltip area, send just the text, and let the chrome figure out how to display it. In the case of Qt, wait for 600 milliseconds of no mouse movement, then display it under the mouse cursor.
2024-07-02 09:16:24 -03:00
view->on_enter_tooltip_area(title);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 13:10:06 -03:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_leave_tooltip_area(u64 page_id)
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 13:10:06 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_leave_tooltip_area)
view->on_leave_tooltip_area();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 13:10:06 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_hover_link(u64 page_id, URL::URL url)
WebContent: Plumb hovered links from WebContent process over to widget Also add a little GUI::StatusBar to the demo app so we can see the hovered link URL's live. :^)
2020-07-05 11:59:20 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_link_hover)
view->on_link_hover(url);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
WebContent: Plumb hovered links from WebContent process over to widget Also add a little GUI::StatusBar to the demo app so we can see the hovered link URL's live. :^)
2020-07-05 11:59:20 -03:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_unhover_link(u64 page_id)
WebContent: Plumb hovered links from WebContent process over to widget Also add a little GUI::StatusBar to the demo app so we can see the hovered link URL's live. :^)
2020-07-05 11:59:20 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_link_unhover)
view->on_link_unhover();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
WebContent: Plumb hovered links from WebContent process over to widget Also add a little GUI::StatusBar to the demo app so we can see the hovered link URL's live. :^)
2020-07-05 11:59:20 -03:00
}
WebContent: Plumb link clicks to the WebContentView :^) You can now react to links being clicked via the on_link_click hook.
2020-07-06 15:01:46 -03:00
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_click_link(u64 page_id, URL::URL url, ByteString target, unsigned modifiers)
WebContent: Plumb link clicks to the WebContentView :^) You can now react to links being clicked via the on_link_click hook.
2020-07-06 15:01:46 -03:00
{
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
if (modifiers == Web::UIEvents::Mod_PlatformCtrl)
Application::the().open_url_in_new_tab(url, Web::HTML::ActivateTab::No);
else if (target == "_blank"sv)
Application::the().open_url_in_new_tab(url, Web::HTML::ActivateTab::Yes);
else if (auto view = view_for_page_id(page_id); view.has_value())
view->load(url);
WebContent: Plumb link clicks to the WebContentView :^) You can now react to links being clicked via the on_link_click hook.
2020-07-06 15:01:46 -03:00
}
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
void WebContentClient::did_middle_click_link(u64, URL::URL url, ByteString, unsigned)
WebContent: Plumb link clicks to the WebContentView :^) You can now react to links being clicked via the on_link_click hook.
2020-07-06 15:01:46 -03:00
{
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
Application::the().open_url_in_new_tab(url, Web::HTML::ActivateTab::No);
LibWeb: Make the WebContentView::on_load_start hook actually work :^)
2020-07-06 16:58:16 -03:00
}
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 07:24:29 -03:00
LibWeb+LibWebView+WebContent+UI: Add an action to cut text
2026-05-06 13:00:59 -03:00
void WebContentClient::did_request_context_menu(u64 page_id, Gfx::IntPoint content_position, Web::ContextMenuForInputEventsTarget for_input_events_target)
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 07:24:29 -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
if (auto view = view_for_page_id(page_id); view.has_value())
LibWeb+LibWebView+WebContent+UI: Add an action to cut text
2026-05-06 13:00:59 -03:00
view->did_request_page_context_menu({}, content_position, for_input_events_target);
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 07:24:29 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_link_context_menu(u64 page_id, Gfx::IntPoint content_position, URL::URL url, ByteString, unsigned)
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 07:24:29 -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
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_request_link_context_menu({}, content_position, move(url));
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 07:24:29 -03:00
}
LibWeb: Move OutOfProcessWebView into the Web namespace
2020-08-24 08:03:18 -03:00
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_image_context_menu(u64 page_id, Gfx::IntPoint content_position, URL::URL url, ByteString, unsigned, Optional<Gfx::ShareableBitmap> bitmap)
LibWeb+WebContent: Support image context menus in OOPWV You can now right-click images in web content and get a context menu.
2021-04-11 11:49:25 -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
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_request_image_context_menu({}, content_position, move(url), move(bitmap));
LibWeb+WebContent: Support image context menus in OOPWV You can now right-click images in web content and get a context menu.
2021-04-11 11:49:25 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_media_context_menu(u64 page_id, Gfx::IntPoint content_position, ByteString, unsigned, Web::Page::MediaContextMenu menu)
Browser+LibWeb+WebContent: Broadcast video element context menu requests This just sets up the IPC to notify the browser process of context menu requests on video elements. The IPC contains a few pieces of information about the state of the video element.
2023-05-15 10:42:56 -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
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_request_media_context_menu({}, content_position, move(menu));
Browser+LibWeb+WebContent: Broadcast video element context menu requests This just sets up the IPC to notify the browser process of context menu requests on video elements. The IPC contains a few pieces of information about the state of the video element.
2023-05-15 10:42:56 -03:00
}
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
void WebContentClient::did_get_source(u64, URL::URL url, URL::URL base_url, String source)
LibWeb: Added get source functionality and hook event
2021-02-23 09:17:23 -03:00
{
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
if (auto view = Application::the().open_blank_new_tab(Web::HTML::ActivateTab::Yes); view.has_value()) {
LibSyntax+LibJS+LibWeb+LibWebView: Remove unused syntax highlighter code A future patch will port LibSyntax away from UTF-32. The less code that needs to be ported, the easier that will be.
2026-06-05 07:39:55 -03:00
auto html = highlight_source(url, base_url, source, Syntax::Language::HTML);
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
view->load_html(html);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb: Added get source functionality and hook event
2021-02-23 09:17:23 -03:00
}
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
static JsonObject parse_json(StringView json, StringView name)
LibWebView: Parse inspector-related JSON strings sooner We currently receive serialized JSON values over IPC and forward them to them WebView callbacks, leaving it to the implementations of those callbacks to parse the strings as JSON objects. This patch hoists that parsing up to WebContentClient as soon as the IPC message is received. This is to reduce the work needed for secondary implementations of these callbacks (i.e. our Firefox DevTools server).
2025-02-21 14:39:43 -03:00
{
auto parsed_tree = JsonValue::from_string(json);
if (parsed_tree.is_error()) {
dbgln("Unable to parse {}: {}", name, parsed_tree.error());
return {};
}
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
if (!parsed_tree.value().is_object()) {
dbgln("Expected {} to be an object: {}", name, parsed_tree.value());
return {};
LibWebView: Parse inspector-related JSON strings sooner We currently receive serialized JSON values over IPC and forward them to them WebView callbacks, leaving it to the implementations of those callbacks to parse the strings as JSON objects. This patch hoists that parsing up to WebContentClient as soon as the IPC message is received. This is to reduce the work needed for secondary implementations of these callbacks (i.e. our Firefox DevTools server).
2025-02-21 14:39:43 -03:00
}
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
return move(parsed_tree.release_value().as_object());
LibWebView: Parse inspector-related JSON strings sooner We currently receive serialized JSON values over IPC and forward them to them WebView callbacks, leaving it to the implementations of those callbacks to parse the strings as JSON objects. This patch hoists that parsing up to WebContentClient as soon as the IPC message is received. This is to reduce the work needed for secondary implementations of these callbacks (i.e. our Firefox DevTools server).
2025-02-21 14:39:43 -03:00
}
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
static JsonArray parse_json_array(StringView json, StringView name)
{
auto parsed_tree = JsonValue::from_string(json);
if (parsed_tree.is_error()) {
dbgln("Unable to parse {}: {}", name, parsed_tree.error());
return {};
}
if (!parsed_tree.value().is_array()) {
dbgln("Expected {} to be an array: {}", name, parsed_tree.value());
return {};
}
return move(parsed_tree.release_value().as_array());
}
static Optional<JsonObject> parse_optional_json_object(StringView json, StringView name)
{
auto parsed_tree = JsonValue::from_string(json);
if (parsed_tree.is_error()) {
dbgln("Unable to parse {}: {}", name, parsed_tree.error());
return {};
}
if (parsed_tree.value().is_null())
return {};
if (!parsed_tree.value().is_object()) {
dbgln("Expected {} to be an object or null: {}", name, parsed_tree.value());
return {};
}
return move(parsed_tree.release_value().as_object());
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_inspect_dom_tree(u64 page_id, String dom_tree)
LibWeb+WebContent: Add IPC flow for Inspect DOM Tree Add `inspect_dom_tree` to WebContentServer and 'did_get_dom_tree' to WebContentClient. These two async methods form a request & response for requesting a JSON representation of the Content's DOM tree.
2021-06-07 12:35:10 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_dom_tree)
LibWebView: Parse inspector-related JSON strings sooner We currently receive serialized JSON values over IPC and forward them to them WebView callbacks, leaving it to the implementations of those callbacks to parse the strings as JSON objects. This patch hoists that parsing up to WebContentClient as soon as the IPC message is received. This is to reduce the work needed for secondary implementations of these callbacks (i.e. our Firefox DevTools server).
2025-02-21 14:39:43 -03:00
view->on_received_dom_tree(parse_json(dom_tree, "DOM tree"sv));
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb+WebContent: Add IPC flow for Inspect DOM Tree Add `inspect_dom_tree` to WebContentServer and 'did_get_dom_tree' to WebContentClient. These two async methods form a request & response for requesting a JSON representation of the Content's DOM tree.
2021-06-07 12:35:10 -03:00
}
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
void WebContentClient::did_inspect_dom_node(u64 page_id, DOMNodeProperties properties)
LibWebView+WebContent: Make the DOM node inspection IPC async
2023-12-30 11:30:27 -03:00
{
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
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_dom_node_properties)
view->on_received_dom_node_properties(move(properties));
LibWebView+WebContent: Make the DOM node inspection IPC async
2023-12-30 11:30:27 -03:00
}
}
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
void WebContentClient::did_inspect_grid_layouts(u64 page_id, String grid_layouts)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_grid_layouts)
view->on_received_grid_layouts(parse_json_array(grid_layouts, "grid layouts"sv));
}
}
void WebContentClient::did_inspect_current_grid(u64 page_id, String grid_layout)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_current_grid)
view->on_received_current_grid(parse_optional_json_object(grid_layout, "current grid"sv));
}
}
WebContent+LibWebView: Add flexbox inspection plumbing
2026-05-27 12:41:13 -03:00
void WebContentClient::did_inspect_current_flexbox(u64 page_id, String flexbox_layout)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_current_flexbox)
view->on_received_current_flexbox(parse_optional_json_object(flexbox_layout, "current flexbox"sv));
}
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_inspect_accessibility_tree(u64 page_id, String accessibility_tree)
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 13:37:31 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_accessibility_tree)
LibWebView: Parse inspector-related JSON strings sooner We currently receive serialized JSON values over IPC and forward them to them WebView callbacks, leaving it to the implementations of those callbacks to parse the strings as JSON objects. This patch hoists that parsing up to WebContentClient as soon as the IPC message is received. This is to reduce the work needed for secondary implementations of these callbacks (i.e. our Firefox DevTools server).
2025-02-21 14:39:43 -03:00
view->on_received_accessibility_tree(parse_json(accessibility_tree, "accessibility tree"sv));
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb+WebContent: Implement asynchronous DOM Node properties call This lets us "push" a new style-properties list to the DOM Inspector, for example when JS changes the style of the inspected node.
2021-08-27 08:47:30 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_get_hovered_node_id(u64 page_id, Web::UniqueNodeID node_id)
LibWebView+WebContent: Make the hovered node retrieval IPC async
2023-12-30 11:42:24 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_hovered_node_id)
view->on_received_hovered_node_id(node_id);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWebView+WebContent: Make the hovered node retrieval IPC async
2023-12-30 11:42:24 -03:00
}
LibWeb+WebContent: Add node picker hit testing Picking needs hit testing in the page process, where layout and event targeting state live. Expose a small page-level query and WebContent IPC entry point that returns the node id at a viewport position. This lets DevTools ask WebContent what the picker is pointing at without duplicating hit-test logic outside LibWeb.
2026-05-28 08:10:27 -03:00
void WebContentClient::did_get_node_id_at_position(u64 page_id, u64 request_id, Web::UniqueNodeID node_id)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
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
view->did_receive_node_picker_hit_test(request_id, node_id);
LibWeb+WebContent: Add node picker hit testing Picking needs hit testing in the page process, where layout and event targeting state live. Expose a small page-level query and WebContent IPC entry point that returns the node id at a viewport position. This lets DevTools ask WebContent what the picker is pointing at without duplicating hit-test logic outside LibWeb.
2026-05-28 08:10:27 -03:00
}
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_finish_editing_dom_node(u64 page_id, Optional<Web::UniqueNodeID> node_id)
LibWebView+WebContent: Make the DOM node editing IPCs async All DOM node mutation IPCs now invoke an async completion IPC after the DOM is mutated. This allows consolidating where the Inspector updates its view and the selected DOM node. This also allows improving the response to removing a DOM node. We would previously just select the <body> tag after removing a DOM node because the Inspector client had no idea what node preceded the removed node. Now the WebContent process can just indicate what that node is. So now after removing a DOM node, we inspect either its previous sibling (if it had one) or its parent.
2023-12-30 12:08:33 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWeb: Fix typos - act II
2025-04-07 07:46:22 -03:00
if (view->on_finished_editing_dom_node)
view->on_finished_editing_dom_node(node_id);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWebView+WebContent: Make the DOM node editing IPCs async All DOM node mutation IPCs now invoke an async completion IPC after the DOM is mutated. This allows consolidating where the Inspector updates its view and the selected DOM node. This also allows improving the response to removing a DOM node. We would previously just select the <body> tag after removing a DOM node because the Inspector client had no idea what node preceded the removed node. Now the WebContent process can just indicate what that node is. So now after removing a DOM node, we inspect either its previous sibling (if it had one) or its parent.
2023-12-30 12:08:33 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_mutate_dom(u64 page_id, Mutation mutation)
LibWeb+LibWebView+WebContent: Inform the UI about DOM mutations This will allow our DevTools server to inform the Firefox DevTools client about DOM mutations.
2025-03-06 19:32:43 -03:00
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_dom_mutation_received)
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
view->on_dom_mutation_received(move(mutation));
LibWeb+LibWebView+WebContent: Inform the UI about DOM mutations This will allow our DevTools server to inform the Firefox DevTools client about DOM mutations.
2025-03-06 19:32:43 -03:00
}
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_get_dom_node_html(u64 page_id, String html)
LibWebView+WebContent: Make the DOM node HTML retrieval IPC async
2023-12-30 16:32:50 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_dom_node_html)
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
view->on_received_dom_node_html(move(html));
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWebView+WebContent: Make the DOM node HTML retrieval IPC async
2023-12-30 16:32:50 -03:00
}
LibWeb+LibWebView+WebContent: Remove the built-in Inspector
2025-03-14 17:22:16 -03:00
void WebContentClient::did_list_style_sheets(u64 page_id, Vector<Web::CSS::StyleSheetIdentifier> stylesheets)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_style_sheet_list)
view->on_received_style_sheet_list(stylesheets);
}
}
void WebContentClient::did_get_style_sheet_source(u64 page_id, Web::CSS::StyleSheetIdentifier identifier, URL::URL base_url, String source)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_style_sheet_source)
view->on_received_style_sheet_source(identifier, base_url, source);
}
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_take_screenshot(u64 page_id, Gfx::ShareableBitmap screenshot)
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 11:51:02 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_receive_screenshot({}, screenshot);
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 11:51:02 -03:00
}
WebContent+LibWebView: Send GC graphs etc over IPC as shared memory These can get very large, exceeding the new IPC message size limits. Instead of serializing them into messages (which was silly anyway) we now send them as Core::AnonymousBuffer which uses shared memory.
2026-02-01 16:18:43 -03:00
void WebContentClient::did_get_internal_page_info(u64 page_id, WebView::PageInfoType type, Optional<Core::AnonymousBuffer> info)
LibWebView+WebContent+headless-browser: Make the page info IPCs async The IPCs to request a page's text, layout tree, etc. are currently all synchronous. This can result in a deadlock when WebContent also makes a synchronous IPC call, as both ends will be waiting on each other. This replaces the page info IPCs with a single, asynchronous IPC. This new IPC is promise-based, much like our screenshot IPC.
2024-09-19 11:40:00 -03:00
{
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_receive_internal_page_info({}, type, info);
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_execute_js_console_input(u64 page_id, JsonValue result)
LibWebView+WebContent: Begin supporting the DevTools JavaScript console This supports evaluating the script and replying with the result. We currently serialize JS objects to a string, but we will need to support dynamic interaction with the objects over IPC. This does not yet support sending console messages to DevTools.
2025-02-24 13:57:33 -03:00
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_received_js_console_result)
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
view->on_received_js_console_result(move(result));
LibWebView+WebContent: Begin supporting the DevTools JavaScript console This supports evaluating the script and replying with the result. We currently serialize JS objects to a string, but we will need to support dynamic interaction with the objects over IPC. This does not yet support sending console messages to DevTools.
2025-02-24 13:57:33 -03:00
}
}
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
void WebContentClient::did_output_js_console_message(u64 page_id, ConsoleOutput console_output)
LibWeb+WebContent: Add new console-message IPC calls This patch introduces three new IPC calls for WebContent: - `Client::did_output_js_console_message(index)`: Notifies the client that a new console message was logged. - `Server::js_console_request_messages(start_index)`: Ask the server for console messages starting at the given index. - `Client::did_get_js_console_messages(start_index, types, messages)`: Send the client the messages they requested. This mechanism will replace the current `Client::did_js_console_output()` call in the next few commits. This will allow us to display messages in the console that happened before the console was opened.
2021-09-04 07:14:25 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
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
if (view->on_console_message)
view->on_console_message(move(console_output));
LibWebView+WebContent: Implement basic DevTools console support
2025-03-04 10:48:20 -03:00
}
}
LibDevTools: Pass request initiator type to network panel Propagate the request initiator type (e.g., "xmlhttprequest", "fetch", "script", "stylesheet") from LibWeb through the IPC layer to DevTools. This enables Firefox DevTools to correctly identify XHR/fetch requests and display appropriate cause types in the Network panel's "Initiator" column.
2026-01-14 19:24:51 -03:00
void WebContentClient::did_start_network_request(u64 page_id, u64 request_id, URL::URL url, ByteString method, Vector<HTTP::Header> request_headers, ByteBuffer request_body, Optional<String> initiator_type)
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
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_network_request_started)
LibDevTools: Pass request initiator type to network panel Propagate the request initiator type (e.g., "xmlhttprequest", "fetch", "script", "stylesheet") from LibWeb through the IPC layer to DevTools. This enables Firefox DevTools to correctly identify XHR/fetch requests and display appropriate cause types in the Network panel's "Initiator" column.
2026-01-14 19:24:51 -03:00
view->on_network_request_started(request_id, url, method, request_headers, move(request_body), move(initiator_type));
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
}
}
void WebContentClient::did_receive_network_response_headers(u64 page_id, u64 request_id, u32 status_code, Optional<String> reason_phrase, Vector<HTTP::Header> response_headers)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_network_response_headers_received)
view->on_network_response_headers_received(request_id, status_code, reason_phrase, response_headers);
}
}
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
void WebContentClient::did_receive_network_response_body(u64 page_id, u64 request_id, ByteBuffer data)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_network_response_body_received)
view->on_network_response_body_received(request_id, move(data));
}
}
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
void WebContentClient::did_finish_network_request(u64 page_id, u64 request_id, u64 body_size, Requests::RequestTimingInfo timing_info, Optional<Requests::NetworkError> network_error)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_network_request_finished)
view->on_network_request_finished(request_id, body_size, timing_info, network_error);
}
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_alert(u64 page_id, String message)
LibWeb: Support window.alert() in multi-process context Alerts are now delegated to the embedding GUI process.
2020-09-12 06:56:13 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_alert)
view->on_request_alert(message);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb: Support window.alert() in multi-process context Alerts are now delegated to the embedding GUI process.
2020-09-12 06:56:13 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_confirm(u64 page_id, String message)
LibWeb+WebContent: Support window.confirm() in OOPWV
2021-02-10 04:48:28 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_confirm)
view->on_request_confirm(message);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb+WebContent: Support window.confirm() in OOPWV
2021-02-10 04:48:28 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_prompt(u64 page_id, String message, String default_)
LibWeb: Implement Window.prompt()
2021-02-20 08:05:18 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_prompt)
view->on_request_prompt(message, default_);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb: Implement Window.prompt()
2021-02-20 08:05:18 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_set_prompt_text(u64 page_id, String message)
LibWeb+LibWebView+WebContent+WebDriver: Implement Send Alert Text
2022-11-16 10:57:05 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_set_prompt_text)
view->on_request_set_prompt_text(message);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb+LibWebView+WebContent+WebDriver: Implement Send Alert Text
2022-11-16 10:57:05 -03:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_request_accept_dialog(u64 page_id)
LibWebView+WebContent: Begin handling open user dialogs for WebDriver The way in which dialogs should be handled is configurable by the driver capabilities object, which we don't support yet. So this implements just the default mode to dismiss the dialog and return an error if there is one open. In the OOPWV, this means we need to refer to the dialog after it has been open, so we now hold a pointer to whatever dialog is open.
2022-11-16 08:58:14 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_accept_dialog)
view->on_request_accept_dialog();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWebView+WebContent: Begin handling open user dialogs for WebDriver The way in which dialogs should be handled is configurable by the driver capabilities object, which we don't support yet. So this implements just the default mode to dismiss the dialog and return an error if there is one open. In the OOPWV, this means we need to refer to the dialog after it has been open, so we now hold a pointer to whatever dialog is open.
2022-11-16 08:58:14 -03:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_request_dismiss_dialog(u64 page_id)
LibWebView+WebContent: Begin handling open user dialogs for WebDriver The way in which dialogs should be handled is configurable by the driver capabilities object, which we don't support yet. So this implements just the default mode to dismiss the dialog and return an error if there is one open. In the OOPWV, this means we need to refer to the dialog after it has been open, so we now hold a pointer to whatever dialog is open.
2022-11-16 08:58:14 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_dismiss_dialog)
view->on_request_dismiss_dialog();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWebView+WebContent: Begin handling open user dialogs for WebDriver The way in which dialogs should be handled is configurable by the driver capabilities object, which we don't support yet. So this implements just the default mode to dismiss the dialog and return an error if there is one open. In the OOPWV, this means we need to refer to the dialog after it has been open, so we now hold a pointer to whatever dialog is open.
2022-11-16 08:58:14 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_change_favicon(u64 page_id, Gfx::ShareableBitmap favicon)
LibWeb+WebContent: Support displaying favicons in OOPWV In single process mode, the browser will display a page's favicon in both the location bar and tab. This adds the same support for multi- process mode.
2021-03-26 11:41:25 -03:00
{
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 14:54:34 -03:00
if (!favicon.is_valid()) {
LibWeb+WebContent: Support displaying favicons in OOPWV In single process mode, the browser will display a page's favicon in both the location bar and tab. This adds the same support for multi- process mode.
2021-03-26 11:41:25 -03:00
dbgln("DidChangeFavicon: Received invalid favicon");
return;
}
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 13:37:31 -03:00
LibWebView: Persist page metadata in history Record visits as soon as a page produces useful metadata such as a title or favicon so pages that never finish loading still become autocomplete candidates. Store favicons in the history schema from the start instead of introducing an upgrade path inside this series, and cover persisted metadata behavior in TestHistoryStore.
2026-04-11 19:33:00 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWeb+LibWebView: Preserve crashed page URLs on crash Load the browser-generated crash page as a synthetic response for the URL that was active when WebContent exited. This keeps the session history entry, response URL, and created Document aligned with the same navigation URL, so reload targets the original page without creating a local document for an HTTP(S) history entry. Suppress history metadata updates from the generated page and declare an inert rel=icon. Fallback favicon loading now follows the HTML condition that no link with the icon keyword exists, which avoids the credentialed /favicon.ico request from the crashed origin.
2026-05-20 11:42:08 -03:00
if (!view->m_should_suppress_history_for_current_load)
maybe_record_history_visit_for_current_load(page_id, view->url(), history_title(view->title(), view->url()), "favicon change"sv);
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
view->set_favicon({}, *favicon.bitmap());
LibWebView: Persist page metadata in history Record visits as soon as a page produces useful metadata such as a title or favicon so pages that never finish loading still become autocomplete candidates. Store favicons in the history schema from the start instead of introducing an upgrade path inside this series, and cover persisted metadata behavior in TestHistoryStore.
2026-04-11 19:33:00 -03:00
}
LibWeb+WebContent: Support displaying favicons in OOPWV In single process mode, the browser will display a page's favicon in both the location bar and tab. This adds the same support for multi- process mode.
2021-03-26 11:41:25 -03:00
}
LibWeb+LibWebView+WebContent: Implement versioning for document cookies This patch introduces a cookie cache in the WebContent process to reduce blocking IPC calls when JS accesses document.cookie. The UI process now maintains a cookie version counter per-domain in shared memory. When JS reads document.cookie, we check whether we have a valid cached cookie by comparing the current shared version to the last used version. If they match, the cached cookie is returned without IPC. This optimization is based on Chromium's shared versioning, in which it was observed that 87% of document.cookie accesses were redundant. See: https://blog.chromium.org/2024/06/introducing-shared-memory-versioning-to.html Note that this cache only supports document.cookie, not HTTP Cookie headers. HTTP cookies are attached to requests with varying URLs and paths. The cookies that match the document URL might not match the request URL, which we wouldn't know from WebContent. So attaching the cached document cookie would be incorrect. On https://twinings.co.uk, we see approximately 600 document.cookie requests while the page loads. This patch reduces the time spent in the document.cookie getter from ~45ms to 2-3ms.
2026-02-01 15:27:19 -03:00
void WebContentClient::did_request_document_cookie_version_index(u64 page_id, i64 document_id, String domain)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (auto document_index = view->ensure_document_cookie_version_index({}, domain); !document_index.is_error())
async_set_document_cookie_version_index(page_id, document_id, document_index.value());
}
}
LibWeb: Implement CookieStore::get(name)
2025-08-05 17:05:45 -03:00
Messages::WebContentClient::DidRequestAllCookiesWebdriverResponse WebContentClient::did_request_all_cookies_webdriver(URL::URL url)
LibWebView+WebContent: Add IPC to get all cookies for a document's URL
2022-11-11 11:23:24 -03:00
{
LibWeb: Implement CookieStore::get(name)
2025-08-05 17:05:45 -03:00
return Application::cookie_jar().get_all_cookies_webdriver(url);
}
Messages::WebContentClient::DidRequestAllCookiesCookiestoreResponse WebContentClient::did_request_all_cookies_cookiestore(URL::URL url)
{
return Application::cookie_jar().get_all_cookies_cookiestore(url);
LibWebView+WebContent: Add IPC to get all cookies for a document's URL
2022-11-11 11:23:24 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
Messages::WebContentClient::DidRequestNamedCookieResponse WebContentClient::did_request_named_cookie(URL::URL url, String name)
LibWebView+WebContent: Add IPC to get a document's named cookie
2022-11-11 11:46:56 -03:00
{
LibWebView+WebContent+UI: Remove cookie related WebView callbacks There's no need for each individual chrome to implement the cookie callbacks. We can handle these entirely within LibWebView.
2024-09-22 14:25:18 -03:00
return Application::cookie_jar().get_named_cookie(url, name);
LibWebView+WebContent: Add IPC to get a document's named cookie
2022-11-11 11:46:56 -03:00
}
LibHTTP+Everywhere: Move the cookie implementation to LibHTTP This will allow parsing cookies outside of LibWeb. LibHTTP is basically becoming the home of HTTP WG specs.
2026-02-07 13:13:47 -03:00
Messages::WebContentClient::DidRequestCookieResponse WebContentClient::did_request_cookie(u64 page_id, URL::URL url, HTTP::Cookie::Source source)
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 11:54:11 -03:00
{
LibHTTP+Everywhere: Move the cookie implementation to LibHTTP This will allow parsing cookies outside of LibWeb. LibHTTP is basically becoming the home of HTTP WG specs.
2026-02-07 13:13:47 -03:00
HTTP::Cookie::VersionedCookie cookie;
LibWeb+LibWebView+WebContent: Implement versioning for document cookies This patch introduces a cookie cache in the WebContent process to reduce blocking IPC calls when JS accesses document.cookie. The UI process now maintains a cookie version counter per-domain in shared memory. When JS reads document.cookie, we check whether we have a valid cached cookie by comparing the current shared version to the last used version. If they match, the cached cookie is returned without IPC. This optimization is based on Chromium's shared versioning, in which it was observed that 87% of document.cookie accesses were redundant. See: https://blog.chromium.org/2024/06/introducing-shared-memory-versioning-to.html Note that this cache only supports document.cookie, not HTTP Cookie headers. HTTP cookies are attached to requests with varying URLs and paths. The cookies that match the document URL might not match the request URL, which we wouldn't know from WebContent. So attaching the cached document cookie would be incorrect. On https://twinings.co.uk, we see approximately 600 document.cookie requests while the page loads. This patch reduces the time spent in the document.cookie getter from ~45ms to 2-3ms.
2026-02-01 15:27:19 -03:00
cookie.cookie = Application::cookie_jar().get_cookie(url, source);
LibHTTP+Everywhere: Move the cookie implementation to LibHTTP This will allow parsing cookies outside of LibWeb. LibHTTP is basically becoming the home of HTTP WG specs.
2026-02-07 13:13:47 -03:00
if (source == HTTP::Cookie::Source::NonHttp) {
LibWeb+LibWebView+WebContent: Implement versioning for document cookies This patch introduces a cookie cache in the WebContent process to reduce blocking IPC calls when JS accesses document.cookie. The UI process now maintains a cookie version counter per-domain in shared memory. When JS reads document.cookie, we check whether we have a valid cached cookie by comparing the current shared version to the last used version. If they match, the cached cookie is returned without IPC. This optimization is based on Chromium's shared versioning, in which it was observed that 87% of document.cookie accesses were redundant. See: https://blog.chromium.org/2024/06/introducing-shared-memory-versioning-to.html Note that this cache only supports document.cookie, not HTTP Cookie headers. HTTP cookies are attached to requests with varying URLs and paths. The cookies that match the document URL might not match the request URL, which we wouldn't know from WebContent. So attaching the cached document cookie would be incorrect. On https://twinings.co.uk, we see approximately 600 document.cookie requests while the page loads. This patch reduces the time spent in the document.cookie getter from ~45ms to 2-3ms.
2026-02-01 15:27:19 -03:00
if (auto view = view_for_page_id(page_id); view.has_value())
cookie.cookie_version = view->document_cookie_version(url);
}
return cookie;
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 11:54:11 -03:00
}
LibHTTP+Everywhere: Move the cookie implementation to LibHTTP This will allow parsing cookies outside of LibWeb. LibHTTP is basically becoming the home of HTTP WG specs.
2026-02-07 13:13:47 -03:00
void WebContentClient::did_set_cookie(URL::URL url, HTTP::Cookie::ParsedCookie cookie, HTTP::Cookie::Source source)
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 11:54:11 -03:00
{
LibWebView+WebContent+UI: Remove cookie related WebView callbacks There's no need for each individual chrome to implement the cookie callbacks. We can handle these entirely within LibWebView.
2024-09-22 14:25:18 -03:00
Application::cookie_jar().set_cookie(url, cookie, source);
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 11:54:11 -03:00
}
LibHTTP+Everywhere: Move the cookie implementation to LibHTTP This will allow parsing cookies outside of LibWeb. LibHTTP is basically becoming the home of HTTP WG specs.
2026-02-07 13:13:47 -03:00
void WebContentClient::did_update_cookie(HTTP::Cookie::Cookie cookie)
LibWebView+WebContent: Add IPC to update a document's cookie
2022-11-11 13:18:40 -03:00
{
LibWebView+WebContent+UI: Remove cookie related WebView callbacks There's no need for each individual chrome to implement the cookie callbacks. We can handle these entirely within LibWebView.
2024-09-22 14:25:18 -03:00
Application::cookie_jar().update_cookie(cookie);
LibWebView+WebContent: Add IPC to update a document's cookie
2022-11-11 13:18:40 -03:00
}
LibWeb+LibWebView: Add an internal API to expire cookies with an offset Cookies have a minimum expiry resolution of 1 second. So to test cookie expiration, the test had to idle for at least a second, which is quite a noticeable delay now that LibWeb tests are parallelized. Instead, we can add an internal API to expire cookies with a time offset to avoid this idle delay.
2024-10-13 09:56:46 -03:00
void WebContentClient::did_expire_cookies_with_time_offset(AK::Duration offset)
{
Application::cookie_jar().expire_cookies_with_time_offset(offset);
}
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
void WebContentClient::did_store_hsts_policy(String domain, HTTP::HSTS::ParsedHSTSPolicy policy)
{
Application::hsts_store().store_policy(domain, policy);
}
Messages::WebContentClient::DidIsKnownHstsHostResponse WebContentClient::did_is_known_hsts_host(String domain)
{
return Application::hsts_store().is_known_hsts_host(domain);
}
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
Messages::WebContentClient::DidRequestStorageItemResponse WebContentClient::did_request_storage_item(Web::StorageAPI::StorageEndpointType storage_endpoint, String storage_key, String bottle_key)
{
return Application::storage_jar().get_item(storage_endpoint, storage_key, bottle_key);
}
Messages::WebContentClient::DidSetStorageItemResponse WebContentClient::did_set_storage_item(Web::StorageAPI::StorageEndpointType storage_endpoint, String storage_key, String bottle_key, String value)
{
return Application::storage_jar().set_item(storage_endpoint, storage_key, bottle_key, value);
}
void WebContentClient::did_remove_storage_item(Web::StorageAPI::StorageEndpointType storage_endpoint, String storage_key, String bottle_key)
{
Application::storage_jar().remove_item(storage_endpoint, storage_key, bottle_key);
}
Messages::WebContentClient::DidRequestStorageKeysResponse WebContentClient::did_request_storage_keys(Web::StorageAPI::StorageEndpointType storage_endpoint, String storage_key)
{
return Application::storage_jar().get_all_keys(storage_endpoint, storage_key);
}
void WebContentClient::did_clear_storage(Web::StorageAPI::StorageEndpointType storage_endpoint, String storage_key)
{
Application::storage_jar().clear_storage_key(storage_endpoint, storage_key);
}
LibWeb: Implement cross process BroadcastChannel delivery Route BroadcastChannel messages over IPC so matching channels can receive them across WebContent and WebWorker processes, rather than only within a single process. Each channel now serializes its payload, sends it upward over IPC, and receiving processes deliver it locally after matching by storage key and channel name.
2026-04-10 16:18:00 -03:00
void WebContentClient::did_post_broadcast_channel_message(u64, Web::HTML::BroadcastChannelMessage message)
{
WebContentClient::for_each_client([&](auto& client) {
if (client.pid() == message.source_process_id)
return IterationDecision::Continue;
client.async_broadcast_channel_message(message);
return IterationDecision::Continue;
});
LibWebView+WebContent+WebWorker: Move worker ownership into LibWebView This lays the groundwork to allow shared workers, nested workers (i.e. workers owned by workers) and service workers to function independently of WebContent.
2026-05-21 10:33:23 -03:00
WorkerProcessManager::the().broadcast_channel_message_from_web_content(message);
LibWeb: Implement cross process BroadcastChannel delivery Route BroadcastChannel messages over IPC so matching channels can receive them across WebContent and WebWorker processes, rather than only within a single process. Each channel now serializes its payload, sends it upward over IPC, and receiving processes deliver it locally after matching by storage key and channel name.
2026-04-10 16:18:00 -03:00
}
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
Messages::WebContentClient::DidRequestNewWebViewResponse WebContentClient::did_request_new_web_view(u64 page_id, Web::HTML::ActivateTab activate_tab, Web::HTML::WebViewHints hints)
LibWeb+LibWebView+WebContent+Ladybird: Add IPC call that opens new tab
2023-03-14 11:12:09 -03:00
{
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
auto new_page_id = Application::the().allocate_page_id();
String handle;
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_new_web_view)
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
handle = view->on_new_web_view(activate_tab, hints, new_page_id);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
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
return { new_page_id, move(handle) };
LibWeb+LibWebView+WebContent+Ladybird: Add IPC call that opens new tab
2023-03-14 11:12:09 -03:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_request_activate_tab(u64 page_id)
WebContent+Everywhere: Add a WebContent IPC to activate a tab
2023-03-20 20:52:00 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_activate_tab)
view->on_activate_tab();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
WebContent+Everywhere: Add a WebContent IPC to activate a tab
2023-03-20 20:52:00 -03:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_close_browsing_context(u64 page_id)
LibWebView+WebContent: Propagate close from WebContent to LibWebView
2023-03-07 00:10:26 -03:00
{
LibWebView: Fast-close pages without beforeunload prompts Track whether WebContent still needs a beforeunload check and let the frontends immediately remove a tab or window when no prompt can be shown. WebContent still receives the close request so pagehide, unload, and cleanup steps can run. When the visible view is removed immediately, keep detached ownership of the WebContent page until it reports that the top-level traversable closed. If no acknowledgement arrives, release detached ownership and ask ProcessManager to shut down the unused WebContent process.
2026-05-26 13:03:07 -03:00
m_detached_pages_pending_close.remove(page_id);
if (auto view = m_views.get(page_id); view.has_value()) {
if ((*view)->on_close)
(*view)->on_close();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWebView: Fast-close pages without beforeunload prompts Track whether WebContent still needs a beforeunload check and let the frontends immediately remove a tab or window when no prompt can be shown. WebContent still receives the close request so pagehide, unload, and cleanup steps can run. When the visible view is removed immediately, keep detached ownership of the WebContent page until it reports that the top-level traversable closed. If no acknowledgement arrives, release detached ownership and ask ProcessManager to shut down the unused WebContent process.
2026-05-26 13:03:07 -03:00
close_server_if_unused();
}
void WebContentClient::did_change_needs_beforeunload_check(u64 page_id, bool needs_beforeunload_check)
{
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_change_needs_beforeunload_check({}, needs_beforeunload_check);
LibWebView+WebContent: Propagate close from WebContent to LibWebView
2023-03-07 00:10:26 -03:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_update_resource_count(u64 page_id, i32 count_waiting)
Browser: Show currently loading host and remaining resource count
2022-02-20 19:03:39 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_resource_status_change)
view->on_resource_status_change(count_waiting);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
Browser: Show currently loading host and remaining resource count
2022-02-20 19:03:39 -03:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_request_restore_window(u64 page_id)
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 11:51:39 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_restore_window)
view->on_restore_window();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 11:51:39 -03:00
}
LibWeb+WebContent+WebDriver+UI: Make window rect updates asynchronous It's currently possible for window size/position updates to hang, as the underlying IPCs are synchronous. This updates the WebDriver endpoint to be async, to unblock the WebContent process while the update is ongoing. The UI process is now responsible for informing WebContent when the update is complete.
2024-10-29 00:37:11 -03:00
void WebContentClient::did_request_reposition_window(u64 page_id, Gfx::IntPoint position)
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 11:51:39 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_reposition_window)
LibWeb+WebContent+WebDriver+UI: Make window rect updates asynchronous It's currently possible for window size/position updates to hang, as the underlying IPCs are synchronous. This updates the WebDriver endpoint to be async, to unblock the WebContent process while the update is ongoing. The UI process is now responsible for informing WebContent when the update is complete.
2024-10-29 00:37:11 -03:00
view->on_reposition_window(position);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 11:51:39 -03:00
}
LibWeb+WebContent+WebDriver+UI: Make window rect updates asynchronous It's currently possible for window size/position updates to hang, as the underlying IPCs are synchronous. This updates the WebDriver endpoint to be async, to unblock the WebContent process while the update is ongoing. The UI process is now responsible for informing WebContent when the update is complete.
2024-10-29 00:37:11 -03:00
void WebContentClient::did_request_resize_window(u64 page_id, Gfx::IntSize size)
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 11:51:39 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_resize_window)
LibWeb+WebContent+WebDriver+UI: Make window rect updates asynchronous It's currently possible for window size/position updates to hang, as the underlying IPCs are synchronous. This updates the WebDriver endpoint to be async, to unblock the WebContent process while the update is ongoing. The UI process is now responsible for informing WebContent when the update is complete.
2024-10-29 00:37:11 -03:00
view->on_resize_window(size);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 11:51:39 -03:00
}
LibWeb+WebContent+WebDriver+UI: Make window min/maximize asynchronous This follows suit of previous changes to never block the WebContent process in WebDriver endpoints.
2024-10-29 00:45:18 -03:00
void WebContentClient::did_request_maximize_window(u64 page_id)
Browser+LibWebView+WebContent: Add IPC to minimize and maximize window Requests to maximize and minimize Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser.
2022-11-09 12:04:09 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_maximize_window)
LibWeb+WebContent+WebDriver+UI: Make window min/maximize asynchronous This follows suit of previous changes to never block the WebContent process in WebDriver endpoints.
2024-10-29 00:45:18 -03:00
view->on_maximize_window();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
Browser+LibWebView+WebContent: Add IPC to minimize and maximize window Requests to maximize and minimize Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser.
2022-11-09 12:04:09 -03:00
}
LibWeb+WebContent+WebDriver+UI: Make window min/maximize asynchronous This follows suit of previous changes to never block the WebContent process in WebDriver endpoints.
2024-10-29 00:45:18 -03:00
void WebContentClient::did_request_minimize_window(u64 page_id)
Browser+LibWebView+WebContent: Add IPC to minimize and maximize window Requests to maximize and minimize Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser.
2022-11-09 12:04:09 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_minimize_window)
LibWeb+WebContent+WebDriver+UI: Make window min/maximize asynchronous This follows suit of previous changes to never block the WebContent process in WebDriver endpoints.
2024-10-29 00:45:18 -03:00
view->on_minimize_window();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
Browser+LibWebView+WebContent: Add IPC to minimize and maximize window Requests to maximize and minimize Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser.
2022-11-09 12:04:09 -03:00
}
WebContent: Remove the sync result from did_request_fullscreen_window This was unused.
2026-03-16 19:38:31 -03:00
void WebContentClient::did_request_fullscreen_window(u64 page_id)
WebDriver: Implement `POST /session/{id}/window/fullscreen` endpoint
2022-11-09 15:09:17 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_fullscreen_window)
LibWeb+WebContent+WebDriver+UI: Make window min/maximize asynchronous This follows suit of previous changes to never block the WebContent process in WebDriver endpoints.
2024-10-29 00:45:18 -03:00
view->on_fullscreen_window();
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWebView+UI/Qt: Allow WebContent to enter/exit the fullscreen UI These IPC methods should be expanded in the future to allow WebContent to specify what UI elements should be kept/removed, for example, the navigation UI.
2025-03-27 11:59:17 -03:00
}
void WebContentClient::did_request_exit_fullscreen(u64 page_id)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_exit_fullscreen_window)
view->on_exit_fullscreen_window();
}
WebDriver: Implement `POST /session/{id}/window/fullscreen` endpoint
2022-11-09 15:09:17 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_file(u64 page_id, ByteString path, i32 request_id)
Browser+LibWeb+WebContent: Allow Browser to load local files To achieve this goal: - The Browser unveils "/tmp/portal/filesystemaccess" - Pass the page through LoadRequest => ResourceLoader - ResourceLoader requests a file to the FileSystemAccessServer via IPC - OutOfProcessWebView handles it and sends a file descriptor back to the Page.
2022-02-26 13:50:31 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_file)
view->on_request_file(path, request_id);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
Browser+LibWeb+WebContent: Allow Browser to load local files To achieve this goal: - The Browser unveils "/tmp/portal/filesystemaccess" - Pass the page through LoadRequest => ResourceLoader - ResourceLoader requests a file to the FileSystemAccessServer via IPC - OutOfProcessWebView handles it and sends a file descriptor back to the Page.
2022-02-26 13:50:31 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_color_picker(u64 page_id, Color current_color)
LibWeb+LibWebView+WebContent: Add support for <input type="color"> This commit introduces 3 things: - Support for the color type in HTMLInputElement itself - A mechanism for handling non event loop blocking dialogs in Page - The associated plumbing up to ViewImplementation Frontends may add support for the color picker with the ViewImplementation.on_request_color_picker function
2023-09-04 06:32:40 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_color_picker)
view->on_request_color_picker(current_color);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb+LibWebView+WebContent: Add support for <input type="color"> This commit introduces 3 things: - Support for the color type in HTMLInputElement itself - A mechanism for handling non event loop blocking dialogs in Page - The associated plumbing up to ViewImplementation Frontends may add support for the color picker with the ViewImplementation.on_request_color_picker function
2023-09-04 06:32:40 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_file_picker(u64 page_id, Web::HTML::FileFilter accepted_file_types, Web::HTML::AllowMultipleFiles allow_multiple_files)
LibWeb+LibWebView+WebContent: Implement more <input type=file> behavior We had previous implemented some plumbing for file input elements in commit 636602a54e55945f7394805975a69dc40934331c. This implements the return path for chromes to inform WebContent of the file(s) the user selected. This patch includes a dummy implementation for headless-browser to enable testing.
2024-02-25 15:02:47 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_file_picker)
view->on_request_file_picker(accepted_file_types, allow_multiple_files);
LibWeb+LibWebView+WebContent: Implement more <input type=file> behavior We had previous implemented some plumbing for file input elements in commit 636602a54e55945f7394805975a69dc40934331c. This implements the return path for chromes to inform WebContent of the file(s) the user selected. This patch includes a dummy implementation for headless-browser to enable testing.
2024-02-25 15:02:47 -03:00
}
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentClient::did_request_select_dropdown(u64 page_id, Gfx::IntPoint content_position, i32 minimum_width, Vector<Web::HTML::SelectItem> items)
Ladybird+LibWeb: Add basic select element support
2023-12-07 11:53:49 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_request_select_dropdown)
LibWebView+UI: Handle DPR for select elements like other menus The select dropdown was doing its own ad-hoc method of handling DPR. We now handle it just like other context menus. Previously, the drop down in the AppKit chrome was twice as large as it should be.
2025-03-21 11:53:59 -03:00
view->on_request_select_dropdown(view->to_widget_position(content_position), minimum_width / view->device_pixel_ratio(), items);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
Ladybird+LibWeb: Add basic select element support
2023-12-07 11:53:49 -03:00
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 13:56:31 -03:00
void WebContentClient::did_finish_handling_input_event(u64 page_id, Web::EventResult event_result)
LibWebView+WebContent: Propagate unconsumed input events out of OOPWV Since 9e2bd9d261a8c0c1b5eeafde95ca310efc667204, the OOPWV has been consuming all mouse and keyboard events, preventing action shortcuts from working. So let's fix that. :^) OOPWV now queues up input events, sending them one at a time to the WebContent process and waiting for the new `did_finish_handling_input_event(bool event_was_accepted) =|` IPC call before sending the next one. If the event was not accepted, OOPWV imitates the usual event bubbling: first passing the event to its superclass, then to its parent widget, and finally propagating to any Action shortcuts. With this, shortcuts like Ctrl+I to open Browser's JS console work again, except when a contenteditable field is selected. That's a whole separate stack of yaks. Co-authored-by: Zaggy1024 <zaggy1024@gmail.com>
2022-11-21 13:07:47 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value())
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 13:56:31 -03:00
view->did_finish_handling_input_event({}, event_result);
LibWebView+WebContent: Propagate unconsumed input events out of OOPWV Since 9e2bd9d261a8c0c1b5eeafde95ca310efc667204, the OOPWV has been consuming all mouse and keyboard events, preventing action shortcuts from working. So let's fix that. :^) OOPWV now queues up input events, sending them one at a time to the WebContent process and waiting for the new `did_finish_handling_input_event(bool event_was_accepted) =|` IPC call before sending the next one. If the event was not accepted, OOPWV imitates the usual event bubbling: first passing the event to its superclass, then to its parent widget, and finally propagating to any Action shortcuts. With this, shortcuts like Ctrl+I to open Browser's JS console work again, except when a contenteditable field is selected. That's a whole separate stack of yaks. Co-authored-by: Zaggy1024 <zaggy1024@gmail.com>
2022-11-21 13:07:47 -03:00
}
LibWeb+UI/AppKit: Implement macOS IME support This makes macOS IME input in web content work as expected. Fixes https://github.com/LadybirdBrowser/ladybird/issues/9712
2026-05-28 11:48:50 -03:00
void WebContentClient::did_update_input_caret_rect(u64 page_id, Optional<Web::DevicePixelRect> rect)
{
if (auto view = view_for_page_id(page_id); view.has_value())
view->set_input_caret_rect({}, rect);
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
void WebContentClient::did_change_theme_color(u64 page_id, Gfx::Color color)
LibWeb+LibWebView+WebContent: Add support for meta theme-color
2023-09-18 20:51:48 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_theme_color_change)
view->on_theme_color_change(color);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWeb+LibWebView+WebContent: Add support for meta theme-color
2023-09-18 20:51:48 -03:00
}
LibWebView: Use page background color while resizing Notify the UI process with the solid canvas background color recorded for the top-level document. This is the Canvas system color with the effective document background composited over it, matching the color used before normal painting. Store that color on the view and use it when AppKit, Qt, and Gtk need to fill areas exposed while an older bitmap is still on screen during a window resize.
2026-05-24 15:44:30 -03:00
void WebContentClient::did_change_background_color(u64 page_id, Gfx::Color color)
{
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_change_background_color({}, color);
}
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
void WebContentClient::did_insert_clipboard_entry(u64, Web::Clipboard::SystemClipboardRepresentation entry, String)
LibWebView+WebContent: Add an IPC hook to insert data into the clipboard
2023-11-10 15:35:41 -03:00
{
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
Application::the().insert_clipboard_entry(move(entry));
LibWeb+LibWebVew+WebContent+UI: Add IPC to retrieve the system clipboard We currently have a single IPC to set clipboard data. We will also need an IPC to retrieve that data from the UI. This defines system clipboard data in LibWeb to handle this transfer, and adds the IPC to provide it.
2025-05-01 12:38:31 -03:00
}
void WebContentClient::did_request_clipboard_entries(u64 page_id, u64 request_id)
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
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
Vector<Web::Clipboard::SystemClipboardItem> items;
if (auto entries = Application::the().clipboard_entries(); !entries.is_empty())
items.empend(move(entries));
view->retrieved_clipboard_entries(request_id, items);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWebView+WebContent: Add an IPC hook to insert data into the clipboard
2023-11-10 15:35:41 -03:00
}
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
void WebContentClient::did_request_primary_paste(u64 page_id)
LibWeb+LibWebView+WebContent: Support primary pasting with middle mouse When the middle mouse button is clicked on a text input control or contenteditable node, we now request the UI process to paste text into that node.
2026-05-15 08:02:20 -03:00
{
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
if (auto view = view_for_page_id(page_id); view.has_value()) {
auto text = Application::the().clipboard_text(Application::ClipboardType::Selection);
view->client().async_paste(page_id, text);
}
LibWeb+LibWebView+WebContent: Support primary pasting with middle mouse When the middle mouse button is clicked on a text input control or contenteditable node, we now request the UI process to paste text into that node.
2026-05-15 08:02:20 -03:00
}
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
void WebContentClient::did_update_primary_selection(u64 page_id, String text)
{
if (auto view = view_for_page_id(page_id); view.has_value())
Application::the().set_clipboard_text(move(text), Application::ClipboardType::Selection);
}
LibWeb+LibWebView+WebContent: Inform chromes when audio is played/paused Most browsers have some indicator when audio is playing in a tab, which makes it easier to find that tab and mute unwanted audio. This adds an IPC to allow the Ladybird chromes to do something similar.
2024-03-26 20:27:06 -03:00
void WebContentClient::did_change_audio_play_state(u64 page_id, Web::HTML::AudioPlayState play_state)
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_change_audio_play_state({}, play_state);
LibWeb+LibWebView+WebContent: Inform chromes when audio is played/paused Most browsers have some indicator when audio is playing in a tab, which makes it easier to find that tab and mute unwanted audio. This adds an IPC to allow the Ladybird chromes to do something similar.
2024-03-26 20:27:06 -03:00
}
LibWeb+LibWebView+WebContent: Add did_update_navigation_buttons_state() It is going to be used to communicate whether it is possible to navigate back or forward after session history stored on browser side will no longer be used to driver navigation.
2024-04-13 18:12:55 -03:00
void WebContentClient::did_update_navigation_buttons_state(u64 page_id, bool back_enabled, bool forward_enabled)
{
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_update_navigation_buttons_state({}, back_enabled, forward_enabled);
}
LibWeb: Present frames through Compositor IPC Introduce a dedicated Compositor IPC channel between the UI process and WebContent. Use it for backing-store setup, presented bitmap delivery, and bitmap-specific ready_to_paint acknowledgements. This makes CompositorThread the single owner of frame presentation bookkeeping before async scrolling starts producing frames without the main thread. Remove old paint and backing-store messages from WebContentClient and PageClient so the UI process no longer observes two presentation protocols.
2026-05-11 16:02:29 -03:00
void WebContentClient::did_present_backing_stores(u64 page_id, i32 front_bitmap_id, Gfx::SharedImage front_backing_store, i32 back_bitmap_id, Gfx::SharedImage back_backing_store)
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 12:50:57 -03:00
{
LibWeb: Add compositor debug logging Trace the compositor state transitions that matter once presentation and async scrolling share one path: page registration, backing-store swaps, did_paint delivery, ready_to_paint acknowledgements, wheel admission, and deferred presents waiting for reusable bitmaps. Keep the logs under COMPOSITOR_DEBUG and use the [Compositor] prefix consistently. The trace is about ownership and backpressure instead of dumping every wheel event detail, so stalls can be diagnosed without reintroducing noisy async-scrolling-only logging.
2026-05-11 16:48:43 -03:00
dbgln_if(COMPOSITOR_DEBUG, "[Compositor] UI received backing stores for page {} front={} back={}",
page_id, front_bitmap_id, back_bitmap_id);
if (auto view = view_for_page_id(page_id); view.has_value()) {
Everywhere: Send IOSurface backing stores via main IPC route on macOS Now that LibIPC uses Mach ports for transport on macOS, IOSurface port rights can be sent as regular IPC message attachments instead of through a separate ad-hoc Mach message side-channel. Introduce Web::SharedBackingStore that wraps either a MachPort (macOS) or ShareableBitmap (other platforms) with IPC encode/decode support, unifying backing store allocation into the existing did_allocate_backing_stores IPC message.
2026-03-23 17:58:03 -03:00
view->did_allocate_backing_stores({}, front_bitmap_id, move(front_backing_store), back_bitmap_id, move(back_backing_store));
LibWeb: Add compositor debug logging Trace the compositor state transitions that matter once presentation and async scrolling share one path: page registration, backing-store swaps, did_paint delivery, ready_to_paint acknowledgements, wheel admission, and deferred presents waiting for reusable bitmaps. Keep the logs under COMPOSITOR_DEBUG and use the [Compositor] prefix consistently. The trace is about ownership and backpressure instead of dumping every wheel event detail, so stalls can be diagnosed without reintroducing noisy async-scrolling-only logging.
2026-05-11 16:48:43 -03:00
} else {
dbgln_if(COMPOSITOR_DEBUG, "[Compositor] UI dropping backing stores for page {} front={} back={}: no view",
page_id, front_bitmap_id, back_bitmap_id);
}
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 12:50:57 -03:00
}
LibWebView+WebContent+WebWorker: Move worker ownership into LibWebView This lays the groundwork to allow shared workers, nested workers (i.e. workers owned by workers) and service workers to function independently of WebContent.
2026-05-21 10:33:23 -03:00
Messages::WebContentClient::StartWorkerAgentResponse WebContentClient::start_worker_agent(u64 page_id, Web::HTML::WorkerAgentStartRequest request)
LibWeb+WebContent: Spawn Worker processes from the chrome Instead of spawning these processes from the WebContent process, we now create them in the Browser chrome. Part 1/N of "all processes are owned by the chrome".
2024-01-06 17:13:59 -03:00
{
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWebView+WebContent+WebWorker: Move worker ownership into LibWebView This lays the groundwork to allow shared workers, nested workers (i.e. workers owned by workers) and service workers to function independently of WebContent.
2026-05-21 10:33:23 -03:00
auto agent_id = WorkerProcessManager::the().start_worker_agent(*this, page_id, move(request));
return { agent_id };
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 22:00:48 -03:00
}
LibWebView+WebContent+WebWorker: Move worker ownership into LibWebView This lays the groundwork to allow shared workers, nested workers (i.e. workers owned by workers) and service workers to function independently of WebContent.
2026-05-21 10:33:23 -03:00
return { 0 };
}
void WebContentClient::close_worker_agent(u64, Web::HTML::WorkerAgentId agent_id, Web::HTML::WorkerAgentOwnerToken owner_token)
{
WorkerProcessManager::the().close_worker_agent(*this, agent_id, owner_token);
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
}
Optional<ViewImplementation&> WebContentClient::view_for_page_id(u64 page_id, SourceLocation location)
{
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
// Don't bother logging anything for the spare WebContent process. It will only receive a load notification for about:blank.
if (m_views.is_empty())
return {};
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
if (auto view = m_views.get(page_id); view.has_value())
return *view.value();
LibWeb+WebContent: Spawn Worker processes from the chrome Instead of spawning these processes from the WebContent process, we now create them in the Browser chrome. Part 1/N of "all processes are owned by the chrome".
2024-01-06 17:13:59 -03:00
LibWebView: Reduce IPC boilerplate within the chrome process Add a small helper function to find the view / log when the view cannot be found.
2024-03-29 10:44:49 -03:00
dbgln("WebContentClient::{}: Did not find a page with ID {}", location.function_name(), page_id);
return {};
LibWeb+WebContent: Spawn Worker processes from the chrome Instead of spawning these processes from the WebContent process, we now create them in the Browser chrome. Part 1/N of "all processes are owned by the chrome".
2024-01-06 17:13:59 -03:00
}
LibWeb: Move OutOfProcessWebView into the Web namespace
2020-08-24 08:03:18 -03:00
}
Reference in a new issue Copy permalink