Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2026-04-19 02:10:26 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWebView/WebUI.cpp

75 lines
1.9 KiB
C++
Raw Normal View History

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
/*
* Copyright (c) 2025, Tim Flynn <trflynn89@ladybird.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibIPC+LibWeb+LibWebView+Services: Add Transport::create_paired() Consolidate the repeated socketpair + adopt + configure pattern from 4 call sites into a single Transport::create_paired() factory method. This fixes inconsistent error handling and socket configuration across call sites, and prepares for future mach port support on macOS.
2026-03-11 13:05:09 +01:00
#include <LibIPC/Transport.h>
LibIPC+LibWeb+LibWebView+Services: Add IPC::TransportHandle Add IPC::TransportHandle as an abstraction for passing IPC transports through .ipc messages. This replaces IPC::File at all sites where a transport (not a generic file) is being transferred between processes. TransportHandle provides from_transport(), clone_from_transport(), and create_transport() methods that encapsulate the fd-to-socket-to-transport conversion in one place. This is preparatory work for Mach port support on macOS -- when that lands, only TransportHandle's internals need to change while all .ipc definitions and call sites remain untouched.
2026-03-11 20:10:08 +01:00
#include <LibIPC/TransportHandle.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/WebContentClient.h>
#include <LibWebView/WebUI.h>
LibWeb+LibWebView+WebContent: Convert about:processes to a WebUI
2025-03-24 09:50:12 -04:00
#include <LibWebView/WebUI/ProcessesUI.h>
LibWeb+LibWebView+WebContent: Convert about:settings to a WebUI
2025-03-24 10:22:38 -04:00
#include <LibWebView/WebUI/SettingsUI.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
namespace WebView {
template<typename WebUIType>
static ErrorOr<NonnullRefPtr<WebUIType>> create_web_ui(WebContentClient& client, String host)
{
LibIPC+LibWeb+LibWebView+Services: Add Transport::create_paired() Consolidate the repeated socketpair + adopt + configure pattern from 4 call sites into a single Transport::create_paired() factory method. This fixes inconsistent error handling and socket configuration across call sites, and prepares for future mach port support on macOS.
2026-03-11 13:05:09 +01:00
auto paired = TRY(IPC::Transport::create_paired());
LibIPC: Return TransportHandle directly from create_paired() Previously, `create_paired()` returned two full Transport objects, and callers would immediately call `from_transport()` on the remote side to extract its underlying fd. This wasted resources: the remote Transport's IO thread, wakeup pipes, and send queue were initialized only to be torn down without ever sending or receiving a message. Now `create_paired()` returns `{Transport, TransportHandle}` — the remote side is born as a lightweight handle containing just the raw fd, skipping all unnecessary initialization. Also replace `release_underlying_transport_for_transfer()` (which returned a raw int fd) with `release_for_transfer()` (which returns a TransportHandle directly), hiding the socket implementation detail from callers including MessagePort.
2026-03-14 17:34:46 +01:00
auto handle = move(paired.remote_handle);
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
LibIPC+LibWeb+LibWebView+Services: Add Transport::create_paired() Consolidate the repeated socketpair + adopt + configure pattern from 4 call sites into a single Transport::create_paired() factory method. This fixes inconsistent error handling and socket configuration across call sites, and prepares for future mach port support on macOS.
2026-03-11 13:05:09 +01:00
auto web_ui = WebUIType::create(client, move(paired.local), move(host));
LibIPC+LibWeb+LibWebView+Services: Add IPC::TransportHandle Add IPC::TransportHandle as an abstraction for passing IPC transports through .ipc messages. This replaces IPC::File at all sites where a transport (not a generic file) is being transferred between processes. TransportHandle provides from_transport(), clone_from_transport(), and create_transport() methods that encapsulate the fd-to-socket-to-transport conversion in one place. This is preparatory work for Mach port support on macOS -- when that lands, only TransportHandle's internals need to change while all .ipc definitions and call sites remain untouched.
2026-03-11 20:10:08 +01:00
client.async_connect_to_web_ui(0, move(handle));
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
return web_ui;
}
LibWeb+LibWebView+WebContent: Convert about:processes to a WebUI
2025-03-24 09:50:12 -04:00
ErrorOr<RefPtr<WebUI>> WebUI::create(WebContentClient& client, String host)
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
{
RefPtr<WebUI> web_ui;
LibWeb+LibWebView+WebContent: Convert about:processes to a WebUI
2025-03-24 09:50:12 -04:00
if (host == "processes"sv)
web_ui = TRY(create_web_ui<ProcessesUI>(client, move(host)));
LibWeb+LibWebView+WebContent: Convert about:settings to a WebUI
2025-03-24 10:22:38 -04:00
else if (host == "settings"sv)
web_ui = TRY(create_web_ui<SettingsUI>(client, move(host)));
LibWeb+LibWebView+WebContent: Convert about:processes to a WebUI
2025-03-24 09:50:12 -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
if (web_ui)
web_ui->register_interfaces();
return web_ui;
}
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
WebUI::WebUI(WebContentClient& client, NonnullOwnPtr<IPC::Transport> transport, String host)
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
: IPC::ConnectionToServer<WebUIClientEndpoint, WebUIServerEndpoint>(*this, move(transport))
, m_client(client)
, m_host(move(host))
{
}
WebUI::~WebUI() = default;
void WebUI::die()
{
m_client.web_ui_disconnected({});
}
void WebUI::register_interface(StringView name, Interface interface)
{
auto result = m_interfaces.set(name, move(interface));
VERIFY(result == HashSetResult::InsertedNewEntry);
}
void WebUI::received_message(String name, JsonValue data)
{
auto interface = m_interfaces.get(name);
if (!interface.has_value()) {
warnln("Received message from WebUI for unrecognized interface: {}", name);
return;
}
interface.value()(move(data));
}
}
Reference in a new issue Copy permalink