Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 13:20:59 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWebView/WebContentClient.cpp

724 lines
24 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 17:31:42 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02: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 17:31:42 +02: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 01:24:48 -07: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 17:31:42 +02:00
*/
Browser+LibWeb+WebContent: Parse cookies in the OOP tab To protect the main Browser process against nefarious cookies, parse the cookies out-of-process and then send the parsed result over IPC to the main process. This way, if the cookie parser blows up, only that tab will be affected.
2021-04-15 10:36:20 -04:00
#include <LibWeb/Cookie/ParsedCookie.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 09:27:36 -04: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 13:25:18 -04:00
#include <LibWebView/CookieJar.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 16:08:08 -05:00
#include <LibWebView/HelperProcess.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 09:08:24 -04: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 09:27:36 -04:00
#include <LibWebView/ViewImplementation.h>
#include <LibWebView/WebContentClient.h>
#include <LibWebView/WebUI.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 17:31:42 +02: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 10:46:33 +02:00
namespace WebView {
LibWeb: Move OutOfProcessWebView into the Web namespace
2020-08-24 15:33:18 +04:30
LibWebView: Allow querying and iterating all extant WebContentClients This is mostly useful when some application-level logic needs to iterate over all child processes. A more robust Process abstraction would make this easier.
2024-06-26 13:43:45 -06:00
HashTable<WebContentClient*> WebContentClient::s_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 21:34:51 +03:00
Optional<ViewImplementation&> WebContentClient::view_for_pid_and_page_id(pid_t pid, u64 page_id)
{
for (auto* client : s_clients) {
if (client->m_process_handle.pid == pid)
return client->view_for_page_id(page_id);
}
return {};
}
Everywhere: Make TransportSocket non-movable Instead of wrapping all non-movable members of TransportSocket in OwnPtr to keep it movable, make TransportSocket itself non-movable and wrap it in OwnPtr.
2025-04-08 22:01:46 +02:00
WebContentClient::WebContentClient(NonnullOwnPtr<IPC::Transport> transport, ViewImplementation& view)
LibIPC+Everywhere: Introduce an IPC Transport abstraction This abstraction will help us to support multiple IPC transport mechanisms going forward. For now, we only have a TransportSocket that implements the same behavior we previously had, using Unix Sockets for IPC.
2024-10-22 15:47:33 -06:00
: IPC::ConnectionToServer<WebContentClientEndpoint, WebContentServerEndpoint>(*this, move(transport))
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 17:31:42 +02: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 21:34:51 +03:00
s_clients.set(this);
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 18:00:48 -07:00
m_views.set(0, &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 17:31:42 +02:00
}
Everywhere: Make TransportSocket non-movable Instead of wrapping all non-movable members of TransportSocket in OwnPtr to keep it movable, make TransportSocket itself non-movable and wrap it in OwnPtr.
2025-04-08 22:01:46 +02:00
WebContentClient::WebContentClient(NonnullOwnPtr<IPC::Transport> transport)
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 18:01:25 -04:00
: IPC::ConnectionToServer<WebContentClientEndpoint, WebContentServerEndpoint>(*this, move(transport))
{
s_clients.set(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 21:34:51 +03:00
WebContentClient::~WebContentClient()
{
s_clients.remove(this);
}
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 18:20:40 +01: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-29 22:24:01 -06: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 18:20:40 +01: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 18:01:25 -04:00
void WebContentClient::assign_view(Badge<Application>, ViewImplementation& view)
{
VERIFY(m_views.is_empty());
m_views.set(0, &view);
}
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 18:00:48 -07: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 17:31:42 +02: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 18:00:48 -07:00
VERIFY(page_id > 0);
m_views.set(page_id, &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 17:31:42 +02: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 18:00:48 -07: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 12:37:31 -04: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 18:00:48 -07:00
m_views.remove(page_id);
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-29 22:24:01 -06:00
if (m_views.is_empty()) {
on_web_content_process_crash = nullptr;
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 19:12:22 -06:00
async_close_server();
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-29 22:24:01 -06: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 18:00:48 -07: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 12:37:31 -04: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 09:27:36 -04:00
void WebContentClient::web_ui_disconnected(Badge<WebUI>)
{
m_web_ui.clear();
}
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 12:22:39 -05:00
void WebContentClient::did_paint(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 18:00:48 -07: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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value())
view->server_did_paint({}, bitmap_id, rect.size());
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 12:37:31 -04: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 11:40:34 -04: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);
}
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 12:22:39 -05: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 17:31:42 +02: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-29 22:24:01 -06: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 14:11:46 -04: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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
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 12:37:31 -04: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 09:44:49 -04:00
if (view->on_load_start)
view->on_load_start(url, 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 17:31:42 +02: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 18:00:18 +02: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 12:22:39 -05: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 19:17:32 +02: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 09:27:36 -04:00
if (url.scheme() == "about"sv && url.paths().size() == 1) {
if (auto web_ui = WebUI::create(*this, url.paths().first()); web_ui.is_error())
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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
view->set_url({}, 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 18:00:48 -07: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 09:44:49 -04:00
if (view->on_load_finish)
view->on_load_finish(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 19:17:32 +02:00
}
LibWeb: Rename internals.signalTextTestIsDone() to signalTestIsDone() In upcoming change this function will be used for ref-tests as well.
2025-03-18 17:37:32 +01:00
void WebContentClient::did_finish_test(u64 page_id, String text)
LibWebView+WebContent: Add IPCs to navigate the browser's history
2022-11-11 13:33:11 -05: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 09:44:49 -04: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 17:37:32 +01: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 18:00:48 -07: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 14:16:05 +00: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 10:24:15 +02: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);
}
}
LibWeb+UI: Add internals API to set browser zoom
2024-12-23 22:15:06 +01:00
void WebContentClient::did_set_browser_zoom(u64 page_id, double factor)
{
LibWebView+UI: Generate the zoom menu
2025-09-10 07:23:15 -04: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 22:15:06 +01: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 12:22:39 -05: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 18:35:32 +01: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 18:00:48 -07:00
void WebContentClient::did_request_refresh(u64 page_id)
LibWebView+WebContent: Add IPCs to navigate the browser's history
2022-11-11 13:33:11 -05:00
{
LibWebView+UI: Remove history traversal WebView callbacks We can handle these entirely within LibWebView.
2024-09-22 13:29:27 -04: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 13:33:11 -05: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 12:22:39 -05:00
void WebContentClient::did_request_cursor_change(u64 page_id, Gfx::Cursor cursor)
LibWeb: Support setting the cursor in OutOfProcessWebView
2021-02-27 21:12:12 +00: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 09:44:49 -04: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 12:17:29 +00: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 09:44:49 -04:00
}
LibWeb: Support setting the cursor in OutOfProcessWebView
2021-02-27 21:12:12 +00:00
}
LibWeb+LibWebView+WebContent+UI: Port the document title to UTF-16
2025-07-28 16:51:01 -04: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 23:40:17 +02: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-29 22:24:01 -06: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 16:51:01 -04: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 14:11:46 -04: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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWeb+LibWebView+WebContent+UI: Port the document title to UTF-16
2025-07-28 16:51:01 -04: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 16:37:30 -04: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 06:43:06 -05:00
if (view->on_title_change)
LibWeb+LibWebView+WebContent+UI: Port the document title to UTF-16
2025-07-28 16:51:01 -04: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 09:44:49 -04: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 23:40:17 +02: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 15:43:43 +02: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 12:22:39 -05:00
void WebContentClient::did_change_url(u64 page_id, URL::URL url)
LibWeb+LibWebView+WebContent: Add did_change_url() IPC call
2024-04-14 10:27:20 +02:00
{
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWebView: Update the stored URL when WebContent's URL changes
2024-04-14 16:59:59 -04:00
view->set_url({}, url);
LibWeb+LibWebView+WebContent: Add did_change_url() IPC call
2024-04-14 10:27:20 +02: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 12:22:39 -05: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 16:48:57 +02: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 12:22:39 -05:00
void WebContentClient::did_enter_tooltip_area(u64 page_id, ByteString title)
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 12:10:06 -04: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 09:44:49 -04: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 14:16:24 +02: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 18:00:48 -07:00
}
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 12:10:06 -04: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 18:00:48 -07:00
void WebContentClient::did_leave_tooltip_area(u64 page_id)
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 12:10:06 -04: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 09:44:49 -04: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 18:00:48 -07:00
}
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 12:10:06 -04: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 12:22:39 -05: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 16:59:20 +02: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 09:44:49 -04: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 18:00:48 -07: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 16:59:20 +02: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 18:00:48 -07: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 16:59:20 +02: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 09:44:49 -04: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 18:00:48 -07: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 16:59:20 +02: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 20:01:46 +02: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 12:22:39 -05: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 20:01:46 +02: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 09:08:24 -04: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 20:01:46 +02: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 09:08:24 -04: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 20:01:46 +02: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 09:08:24 -04: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 21:58:16 +02: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 12:24:29 +02: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 18:00:48 -07:00
void WebContentClient::did_request_context_menu(u64 page_id, Gfx::IntPoint content_position)
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 12:24:29 +02: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 08:20:14 -04:00
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_request_page_context_menu({}, content_position);
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 12:24:29 +02: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 12:22:39 -05: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 12:24:29 +02: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 08:20:14 -04: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 12:24:29 +02:00
}
LibWeb: Move OutOfProcessWebView into the Web namespace
2020-08-24 15:33:18 +04:30
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 12:22:39 -05: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 16:49:25 +02: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 08:20:14 -04: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 16:49:25 +02: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 12:22:39 -05: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 09:42:56 -04: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 08:20:14 -04: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 09:42:56 -04: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 09:08:24 -04: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 06:17:23 -06: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 09:08:24 -04:00
if (auto view = Application::the().open_blank_new_tab(Web::HTML::ActivateTab::Yes); view.has_value()) {
auto html = highlight_source(url, base_url, source, Syntax::Language::HTML, WebView::HighlightOutputMode::FullDocument);
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 18:00:48 -07:00
}
LibWeb: Added get source functionality and hook event
2021-02-23 06:17:23 -06: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 15:50:56 -04: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 12:39:43 -05: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 15:50:56 -04: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 12:39:43 -05: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 15:50:56 -04: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 12:39:43 -05: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 12:22:39 -05: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 16:35:10 +01: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 09:44:49 -04: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 12:39:43 -05: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 18:00:48 -07: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 16:35:10 +01: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 15:50:56 -04:00
void WebContentClient::did_inspect_dom_node(u64 page_id, DOMNodeProperties properties)
LibWebView+WebContent: Make the DOM node inspection IPC async
2023-12-30 09:30:27 -05: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 15:50:56 -04: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 09:30:27 -05: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 12:22:39 -05: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 12:37:31 -04: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 09:44:49 -04: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 12:39:43 -05: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 18:00:48 -07: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 12:47:30 +01: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 12:22:39 -05: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 09:42:24 -05: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 09:44:49 -04: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 18:00:48 -07:00
}
LibWebView+WebContent: Make the hovered node retrieval IPC async
2023-12-30 09:42:24 -05: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 12:22:39 -05: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 10:08:33 -05: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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWeb: Fix typos - act II
2025-04-07 10:46:22 +00: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 18:00:48 -07: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 10:08:33 -05: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 12:22:39 -05: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 17:32:43 -05: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 12:22:39 -05: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 17:32:43 -05: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 12:22:39 -05: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 14:32:50 -05: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 09:44:49 -04: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 17:36:41 -04: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 18:00:48 -07:00
}
LibWebView+WebContent: Make the DOM node HTML retrieval IPC async
2023-12-30 14:32:50 -05:00
}
LibWeb+LibWebView+WebContent: Remove the built-in Inspector
2025-03-14 16:22:16 -04: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 12:22:39 -05: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 09:51:02 -05: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 09:44:49 -04: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 09:51:02 -05: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 12:22:39 -05:00
void WebContentClient::did_get_internal_page_info(u64 page_id, WebView::PageInfoType type, String 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 10:40:00 -04: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 12:22:39 -05: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 11:57:33 -05: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 12:22:39 -05: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 11:57:33 -05: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 18:00:48 -07:00
void WebContentClient::did_output_js_console_message(u64 page_id, i32 message_index)
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 11:14:25 +01: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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWebView: Rename a couple of console-related callbacks for clarity The "on_received_console_message" and "on_received_console_messages" were indistinguishable in purpose based on their name. This renames them to: on_console_message_available - WebContent has output a console message and it is available for the client to retrieve. on_received_styled_console_messages - WebContent has replied to a request for the available console messages. The "styled" qualifier is used here to indicate that the messages have been styled with CSS for display in a WebView. This is to prepare for an upcoming patch where DevToolsConsoleClient will not stylize the output; DevTools will want the raw JS values.
2025-03-04 07:56:42 -05:00
if (view->on_console_message_available)
view->on_console_message_available(message_index);
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 18:00:48 -07:00
}
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 11:14:25 +01:00
}
LibWebView+WebContent: Remove "styled" JS console IPC hooks This was used by the built-in Inspector to send HTML-ified JS console messages to the browser. It is no longer used.
2025-03-25 10:11:17 -04:00
void WebContentClient::did_get_js_console_messages(u64 page_id, i32 start_index, Vector<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 11:14:25 +01: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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWebView+WebContent: Remove "styled" JS console IPC hooks This was used by the built-in Inspector to send HTML-ified JS console messages to the browser. It is no longer used.
2025-03-25 10:11:17 -04:00
if (view->on_received_console_messages)
view->on_received_console_messages(start_index, move(console_output));
LibWebView+WebContent: Implement basic DevTools console support
2025-03-04 08:48:20 -05: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 12:22:39 -05: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 11:56:13 +02: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 09:44:49 -04: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 18:00:48 -07:00
}
LibWeb: Support window.alert() in multi-process context Alerts are now delegated to the embedding GUI process.
2020-09-12 11:56:13 +02: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 12:22:39 -05:00
void WebContentClient::did_request_confirm(u64 page_id, String message)
LibWeb+WebContent: Support window.confirm() in OOPWV
2021-02-10 08:48:28 +01: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 09:44:49 -04: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 18:00:48 -07:00
}
LibWeb+WebContent: Support window.confirm() in OOPWV
2021-02-10 08:48:28 +01: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 12:22:39 -05:00
void WebContentClient::did_request_prompt(u64 page_id, String message, String default_)
LibWeb: Implement Window.prompt()
2021-02-20 12:05:18 +01: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 09:44:49 -04: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 18:00:48 -07:00
}
LibWeb: Implement Window.prompt()
2021-02-20 12:05:18 +01: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 12:22:39 -05:00
void WebContentClient::did_request_set_prompt_text(u64 page_id, String message)
LibWeb+LibWebView+WebContent+WebDriver: Implement Send Alert Text
2022-11-16 08:57:05 -05: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 09:44:49 -04: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 18:00:48 -07:00
}
LibWeb+LibWebView+WebContent+WebDriver: Implement Send Alert Text
2022-11-16 08:57:05 -05: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 18:00:48 -07: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 06:58:14 -05: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 09:44:49 -04: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 18:00:48 -07: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 06:58:14 -05: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 18:00:48 -07: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 06:58:14 -05: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 09:44:49 -04: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 18:00:48 -07: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 06:58:14 -05: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 12:22:39 -05: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 10:41:25 -04: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 19:54:34 +02: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 10:41:25 -04: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 12:37:31 -04: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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_favicon_change)
view->on_favicon_change(*favicon.bitmap());
}
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 10:41:25 -04:00
}
LibWeb: Implement CookieStore::get(name)
2025-08-05 23: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 09:23:24 -05:00
{
LibWeb: Implement CookieStore::get(name)
2025-08-05 23: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 09:23:24 -05: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 12:22:39 -05: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 09:46:56 -05: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 13:25:18 -04:00
return Application::cookie_jar().get_named_cookie(url, name);
LibWebView+WebContent: Add IPC to get a document's named cookie
2022-11-11 09:46:56 -05: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 12:22:39 -05:00
Messages::WebContentClient::DidRequestCookieResponse WebContentClient::did_request_cookie(URL::URL url, Web::Cookie::Source source)
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 10:54:11 -04: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 13:25:18 -04:00
return Application::cookie_jar().get_cookie(url, source);
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 10:54:11 -04: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 12:22:39 -05:00
void WebContentClient::did_set_cookie(URL::URL url, Web::Cookie::ParsedCookie cookie, Web::Cookie::Source source)
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 10:54:11 -04: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 13:25:18 -04:00
Application::cookie_jar().set_cookie(url, cookie, source);
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 10:54:11 -04: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 12:22:39 -05:00
void WebContentClient::did_update_cookie(Web::Cookie::Cookie cookie)
LibWebView+WebContent: Add IPC to update a document's cookie
2022-11-11 11:18:40 -05: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 13:25:18 -04:00
Application::cookie_jar().update_cookie(cookie);
LibWebView+WebContent: Add IPC to update a document's cookie
2022-11-11 11:18:40 -05: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 08:56:46 -04:00
void WebContentClient::did_expire_cookies_with_time_offset(AK::Duration offset)
{
Application::cookie_jar().expire_cookies_with_time_offset(offset);
}
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 23:35:46 +02: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);
}
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 12:22:39 -05:00
Messages::WebContentClient::DidRequestNewWebViewResponse WebContentClient::did_request_new_web_view(u64 page_id, Web::HTML::ActivateTab activate_tab, Web::HTML::WebViewHints hints, Optional<u64> page_index)
LibWeb+LibWebView+WebContent+Ladybird: Add IPC call that opens new tab
2023-03-14 17:12: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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
if (view->on_new_web_view)
return view->on_new_web_view(activate_tab, hints, page_index);
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 18:00:48 -07: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 12:37:31 -04:00
return String {};
LibWeb+LibWebView+WebContent+Ladybird: Add IPC call that opens new tab
2023-03-14 17: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 18:00:48 -07:00
void WebContentClient::did_request_activate_tab(u64 page_id)
WebContent+Everywhere: Add a WebContent IPC to activate a tab
2023-03-20 19:52:00 -04: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 09:44:49 -04: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 18:00:48 -07:00
}
WebContent+Everywhere: Add a WebContent IPC to activate a tab
2023-03-20 19:52:00 -04: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 18:00:48 -07:00
void WebContentClient::did_close_browsing_context(u64 page_id)
LibWebView+WebContent: Propagate close from WebContent to LibWebView
2023-03-07 06:10:26 +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 09:44:49 -04:00
if (auto view = view_for_page_id(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 18:00:48 -07:00
}
LibWebView+WebContent: Propagate close from WebContent to LibWebView
2023-03-07 06: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 18:00:48 -07: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 17:03:39 -05: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 09:44:49 -04: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 18:00:48 -07:00
}
Browser: Show currently loading host and remaining resource count
2022-02-20 17:03:39 -05: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 18:00:48 -07: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 09:51:39 -05: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 09:44:49 -04: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 18:00:48 -07: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 09:51:39 -05: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-28 23:37:11 -04: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 09:51:39 -05: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 09:44:49 -04: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-28 23:37:11 -04: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 18:00:48 -07: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 09:51:39 -05: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-28 23:37:11 -04: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 09:51:39 -05: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 09:44:49 -04: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-28 23:37:11 -04: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 18:00:48 -07: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 09:51:39 -05: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-28 23:45:18 -04: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 10:04:09 -05: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 09:44:49 -04: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-28 23:45:18 -04: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 18:00:48 -07: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 10:04:09 -05: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-28 23:45:18 -04: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 10:04:09 -05: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 09:44:49 -04: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-28 23:45:18 -04: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 18:00:48 -07: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 10:04:09 -05: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-28 23:45:18 -04:00
void WebContentClient::did_request_fullscreen_window(u64 page_id)
WebDriver: Implement `POST /session/{id}/window/fullscreen` endpoint
2022-11-09 19:09:17 +01: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 09:44:49 -04: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-28 23:45:18 -04: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 18:00:48 -07:00
}
WebDriver: Implement `POST /session/{id}/window/fullscreen` endpoint
2022-11-09 19:09:17 +01: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 12:22:39 -05: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 17:50:31 +01: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 09:44:49 -04: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 18:00:48 -07: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 17:50:31 +01: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 12:22:39 -05: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 11:32:40 +02: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 09:44:49 -04: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 18:00:48 -07: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 11:32:40 +02: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 12:22:39 -05: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 13:02:47 -05: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 09:44:49 -04: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 13:02:47 -05: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 12:22:39 -05: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 15:53:49 +01: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 09:44:49 -04: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 10:53:59 -04: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 18:00:48 -07:00
}
Ladybird+LibWeb: Add basic select element support
2023-12-07 15:53:49 +01: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 12:56:31 -04: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 16:07:47 +00: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 09:44:49 -04: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 12:56:31 -04: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 16:07:47 +00: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 18:00:48 -07:00
void WebContentClient::did_change_theme_color(u64 page_id, Gfx::Color color)
LibWeb+LibWebView+WebContent: Add support for meta theme-color
2023-09-19 01:51:48 +02: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 09:44:49 -04: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 18:00:48 -07:00
}
LibWeb+LibWebView+WebContent: Add support for meta theme-color
2023-09-19 01:51:48 +02: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 08:16:36 -04: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 13:35:41 -05: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 08:16:36 -04: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 11:38:31 -04: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 08:16:36 -04: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 18:00:48 -07:00
}
LibWebView+WebContent: Add an IPC hook to insert data into the clipboard
2023-11-10 13:35:41 -05:00
}
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 19:27:06 -04: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 09:44:49 -04: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 19:27:06 -04: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 23:12:55 +02: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);
}
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 12:22:39 -05:00
void WebContentClient::did_allocate_backing_stores(u64 page_id, i32 front_bitmap_id, Gfx::ShareableBitmap front_bitmap, i32 back_bitmap_id, Gfx::ShareableBitmap back_bitmap)
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 18:50:57 +03:00
{
if (auto view = view_for_page_id(page_id); view.has_value())
view->did_allocate_backing_stores({}, front_bitmap_id, front_bitmap, back_bitmap_id, back_bitmap);
}
LibWeb+LibWebView+Services: Add IPC for starting WebWorker of a type The provides some of the plumbing for a WebContent process to spin up a WebWorker that is not just a dedicated worker.
2025-04-24 17:07:09 +12:00
Messages::WebContentClient::RequestWorkerAgentResponse WebContentClient::request_worker_agent(u64 page_id, Web::Bindings::AgentType worker_type)
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 13:13:59 -07: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 09:44:49 -04:00
if (auto view = view_for_page_id(page_id); view.has_value()) {
LibWeb+LibWebView+Services: Add IPC for starting WebWorker of a type The provides some of the plumbing for a WebContent process to spin up a WebWorker that is not just a dedicated worker.
2025-04-24 17:07:09 +12:00
auto worker_client = MUST(WebView::launch_web_worker_process(worker_type));
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 16:08:08 -05:00
return worker_client->clone_transport();
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 18:00:48 -07:00
}
Ladybird+Userland: Remove use of unnecessary fd passing socket concept Now that LibIPC is using SCM_RIGHTS properly, we can go back to only having one socket laying around when needing to transfer fds to peers.
2024-04-17 18:44:39 -06:00
return IPC::File {};
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 09:44:49 -04: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 18:01:25 -04: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 09:44:49 -04: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 13:13:59 -07: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 09:44:49 -04: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 13:13:59 -07:00
}
LibWeb: Move OutOfProcessWebView into the Web namespace
2020-08-24 15:33:18 +04:30
}
Reference in a new issue Copy permalink