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

1194 lines
52 KiB
C++
Raw Normal View History

LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
/*
* Copyright (c) 2024, Andrew Kaster <akaster@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <AK/Debug.h>
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
#include <LibCore/ArgsParser.h>
LibWebView+WebContent: Monitor for system time zone changes This creates a TimeZoneWatcher in the UI process to inform all open WebContent processes when the time zone changes. The WebContent process will clear its time zone cache to retrieve a fresh zone the next time it is asked for one.
2024-08-24 12:15:20 -04:00
#include <LibCore/Environment.h>
LibWebView: Add facilities to ask the user for a download directory If the Downloads directory exists, we will use it (note that this will respect the XDG_DOWNLOAD_DIR environment variable). Otherwise, we will ask the UI layer to retrieve a download directory from the user. This directory is not saved, so it will be re-prompted every time. Once a proper settings UI is complete, we will of course integrate with that for persistent settings.
2024-08-28 15:29:51 -04:00
#include <LibCore/StandardPaths.h>
LibWebView: Increase the open file limit in a more central location We don't create a ChromeProcess in headless-browser, so it is currently not increasing it's open file limit. This is causing crashes on macOS, which has a very low default limit.
2024-10-07 13:36:17 -04:00
#include <LibCore/System.h>
LibWebView+WebContent: Monitor for system time zone changes This creates a TimeZoneWatcher in the UI process to inform all open WebContent processes when the time zone changes. The WebContent process will clear its time zone cache to retrieve a fresh zone the next time it is asked for one.
2024-08-24 12:15:20 -04:00
#include <LibCore/TimeZoneWatcher.h>
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
#include <LibDevTools/DevToolsServer.h>
LibWebView: Add facilities to ask the user for a download directory If the Downloads directory exists, we will use it (note that this will respect the XDG_DOWNLOAD_DIR environment variable). Otherwise, we will ask the UI layer to retrieve a download directory from the user. This directory is not saved, so it will be re-prompted every time. Once a proper settings UI is complete, we will of course integrate with that for persistent settings.
2024-08-28 15:29:51 -04:00
#include <LibFileSystem/FileSystem.h>
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
#include <LibImageDecoderClient/Client.h>
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
#include <LibWeb/CSS/PropertyID.h>
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 09:00:52 -04:00
#include <LibWeb/Loader/UserAgent.h>
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
#include <LibWebView/Application.h>
LibWebView+UI: Move the database and cookie jar to WebView::Application The main motivator here was noticing that --disable-sql-database did not work with AppKit. Rather than re-implementing this there, move ownership of these classes to WebView::Application, so that each UI does not need to individually worry about it.
2024-09-05 18:19:51 -04:00
#include <LibWebView/CookieJar.h>
#include <LibWebView/Database.h>
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
#include <LibWebView/HeadlessWebView.h>
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
#include <LibWebView/HelperProcess.h>
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
#include <LibWebView/Menu.h>
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
#include <LibWebView/URL.h>
LibWebView: Add a command line option to override the User-Agent This commit just adds a command line option to case-insensitively accept a User-Agent name to use as the UA override. The UIs will individually need to make use of this option.
2024-08-28 10:26:11 -04:00
#include <LibWebView/UserAgent.h>
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
#include <LibWebView/Utilities.h>
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
#include <LibWebView/WebContentClient.h>
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 19:20:46 -04:00
#if defined(AK_OS_MACOS)
# include <LibWebView/MachPortServer.h>
#endif
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
namespace WebView {
Application* Application::s_the = nullptr;
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 12:37:05 -04:00
struct ApplicationSettingsObserver : public SettingsObserver {
virtual void dns_settings_changed() override
{
Application::settings().dns_settings().visit(
[](SystemDNS) {
Application::request_server_client().async_set_use_system_dns();
},
[](DNSOverTLS const& dns_over_tls) {
LibWebView+RequestSever: Wire up a validate-DNSSEC setting option to RS
2025-05-13 12:34:55 +02:00
dbgln("Setting DNS server to {}:{} with TLS ({} local dnssec)", dns_over_tls.server_address, dns_over_tls.port, dns_over_tls.validate_dnssec_locally ? "with" : "without");
Application::request_server_client().async_set_dns_server(dns_over_tls.server_address, dns_over_tls.port, true, dns_over_tls.validate_dnssec_locally);
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 12:37:05 -04:00
},
[](DNSOverUDP const& dns_over_udp) {
LibWebView+RequestSever: Wire up a validate-DNSSEC setting option to RS
2025-05-13 12:34:55 +02:00
dbgln("Setting DNS server to {}:{} ({} local dnssec)", dns_over_udp.server_address, dns_over_udp.port, dns_over_udp.validate_dnssec_locally ? "with" : "without");
Application::request_server_client().async_set_dns_server(dns_over_udp.server_address, dns_over_udp.port, false, dns_over_udp.validate_dnssec_locally);
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 12:37:05 -04:00
});
}
};
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 19:20:46 -04:00
Application::Application(Optional<ByteString> ladybird_binary_path)
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 12:37:05 -04:00
: m_settings(Settings::create({}))
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
{
VERIFY(!s_the);
s_the = this;
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 19:20:46 -04:00
platform_init(move(ladybird_binary_path));
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
}
Application::~Application()
{
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 12:37:05 -04:00
// Explicitly delete the settings observer first, as the observer destructor will refer to Application::the().
m_settings_observer.clear();
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
s_the = nullptr;
}
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 19:20:46 -04:00
ErrorOr<void> Application::initialize(Main::Arguments const& arguments)
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
{
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 19:20:46 -04:00
TRY(handle_attached_debugger());
LibWebView+UI: Do not create a QApplication in headless mode This is causing errors on the WPT runner, which does not have a display output. To do this requires shuffling around the Main::Arguments struct, as we now need access to it from overridden WebView::Application methods after construction.
2025-06-10 14:56:24 -04:00
m_arguments = arguments;
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 19:20:46 -04:00
#if !defined(AK_OS_WINDOWS)
LibWebView: Increase the open file limit in a more central location We don't create a ChromeProcess in headless-browser, so it is currently not increasing it's open file limit. This is causing crashes on macOS, which has a very low default limit.
2024-10-07 13:36:17 -04:00
// Increase the open file limit, as the default limits on Linux cause us to run out of file descriptors with around 15 tabs open.
if (auto result = Core::System::set_resource_limits(RLIMIT_NOFILE, 8192); result.is_error())
warnln("Unable to increase open file limit: {}", result.error());
LibWebView: Port to Windows
2024-12-21 16:19:39 +05:00
#endif
LibWebView: Increase the open file limit in a more central location We don't create a ChromeProcess in headless-browser, so it is currently not increasing it's open file limit. This is causing crashes on macOS, which has a very low default limit.
2024-10-07 13:36:17 -04:00
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 19:20:46 -04:00
#if defined(AK_OS_MACOS)
m_mach_port_server = make<MachPortServer>();
set_mach_server_name(m_mach_port_server->server_port_name());
m_mach_port_server->on_receive_child_mach_port = [this](auto pid, auto port) {
set_process_mach_port(pid, move(port));
};
m_mach_port_server->on_receive_backing_stores = [](MachPortServer::BackingStoresMessage message) {
if (auto view = WebContentClient::view_for_pid_and_page_id(message.pid, message.page_id); view.has_value())
view->did_allocate_iosurface_backing_stores(message.front_backing_store_id, move(message.front_backing_store_port), message.back_backing_store_id, move(message.back_backing_store_port));
};
#endif
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
Vector<ByteString> raw_urls;
Vector<ByteString> certificates;
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
Optional<HeadlessMode> headless_mode;
Optional<int> window_width;
Optional<int> window_height;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
bool new_window = false;
bool force_new_process = false;
bool allow_popups = false;
UI: Add the `--disable-scripting` option to disable scripting by default
2024-09-04 07:13:40 +01:00
bool disable_scripting = false;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
bool disable_sql_database = false;
LibWebView+UI: Launch the DevTools server if --devtools is specified This replaces the --devtools-port flag with a --devtools flag, which optionally accepts a port. If the --devtools flag is set, we will now automatically launch the DevTools server.
2025-07-02 12:42:53 -04:00
Optional<u16> devtools_port;
LibWebView+UI: Allow debugging any helper process This removes the --debug-web-content flag, and replaces it with a --debug-process=<process-name> flag. For example: ladybird --debug-process=WebContent ladybird --debug-process=RequestServer This allows attaching gdb to any helper process.
2024-08-01 07:03:03 -04:00
Optional<StringView> debug_process;
LibWebView+UI: Allow profiling any helper process This removes the --enable-callgrind-profiling flag, and replaces it with a --profile-process=<process-name> flag. For example: ladybird --profile-process=WebContent ladybird --profile-process=RequestServer This allows profiling any helper process with callgrind.
2024-08-01 07:13:09 -04:00
Optional<StringView> profile_process;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
Optional<StringView> webdriver_content_ipc_path;
LibWebView: Add a command line option to override the User-Agent This commit just adds a command line option to case-insensitively accept a User-Agent name to use as the UA override. The UIs will individually need to make use of this option.
2024-08-28 10:26:11 -04:00
Optional<StringView> user_agent_preset;
LibDNS+LibWeb+Ladybird+RequestServer: Let there be DNS over TLS This commit adds our own DNS resolver, with the aim of implementing DoT (and eventually DoH, maybe even DNSSEC etc.)
2024-11-01 23:53:43 +01:00
Optional<StringView> dns_server_address;
Optional<u16> dns_server_port;
bool use_dns_over_tls = false;
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
bool layout_test_mode = false;
LibWebView+RequestSever: Wire up a validate-DNSSEC setting option to RS
2025-05-13 12:34:55 +02:00
bool validate_dnssec_locally = false;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
bool log_all_js_exceptions = false;
LibWebView+WebContent: Add a command-line flag to disable site isolation
2025-03-11 19:25:34 -04:00
bool disable_site_isolation = false;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
bool enable_idl_tracing = false;
LibWebView: Enable HTTP cache by default The HTTP cache is now stable enough that we can ask more people to help us testing it. So let's turn it on by default! It can be turned off with --disable-http-cache if needed.
2025-09-07 22:40:15 +02:00
bool disable_http_cache = false;
UI: Add an option to enable autoplay globally
2024-09-22 23:12:36 +01:00
bool enable_autoplay = false;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
bool expose_internals_object = false;
LibWebView+WebContent: Add a `--force-cpu-painting` option This option forces Skia to use the CPU backend rather than using the GPU.
2024-08-01 18:49:24 +01:00
bool force_cpu_painting = false;
Ladybird+LibWeb+LibGfx: Add option to force use of fontconfig This allows us to get identical metrics on macOS and Linux. Without this, Skia will use CoreText on macOS and give us slightly different text metrics. That causes layout tests to be slightly different on different platforms, which is a huge headache. So let's not do that. You can now launch Ladybird and headless-browser with --force-fontconfig to load fonts through fontconfig. Tests run in this mode by default.
2024-08-19 20:35:49 +02:00
bool force_fontconfig = false;
LibWebView: Add a browser flag to collect garbage after each allocation
2024-10-31 11:06:01 -04:00
bool collect_garbage_on_every_allocation = false;
LibWebView: Add an option to disable painting viewport scrollbars
2024-12-16 11:23:10 +00:00
bool disable_scrollbar_painting = false;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
Core::ArgsParser args_parser;
args_parser.set_general_help("The Ladybird web browser :^)");
args_parser.add_positional_argument(raw_urls, "URLs to open", "url", Core::ArgsParser::Required::No);
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
args_parser.add_option(Core::ArgsParser::Option {
.argument_mode = Core::ArgsParser::OptionArgumentMode::Optional,
.help_string = "Run Ladybird without a browser window. Mode may be 'screenshot' (default), 'layout-tree', or 'text'.",
.long_name = "headless",
.value_name = "mode",
.accept_value = [&](StringView value) {
if (headless_mode.has_value())
return false;
if (value.is_empty() || value.equals_ignoring_ascii_case("screenshot"sv))
headless_mode = HeadlessMode::Screenshot;
else if (value.equals_ignoring_ascii_case("layout-tree"sv))
headless_mode = HeadlessMode::LayoutTree;
else if (value.equals_ignoring_ascii_case("text"sv))
headless_mode = HeadlessMode::Text;
return headless_mode.has_value();
},
});
args_parser.add_option(window_width, "Set viewport width in pixels (default: 800) (currently only supported for headless mode)", "window-width", 0, "pixels");
args_parser.add_option(window_height, "Set viewport height in pixels (default: 600) (currently only supported for headless mode)", "window-height", 0, "pixels");
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
args_parser.add_option(certificates, "Path to a certificate file", "certificate", 'C', "certificate");
args_parser.add_option(new_window, "Force opening in a new window", "new-window", 'n');
Everywhere: Replace miscellaneous references to the chrome process
2025-03-15 17:20:05 -04:00
args_parser.add_option(force_new_process, "Force creation of a new browser process", "force-new-process");
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
args_parser.add_option(allow_popups, "Disable popup blocking by default", "allow-popups");
UI: Add the `--disable-scripting` option to disable scripting by default
2024-09-04 07:13:40 +01:00
args_parser.add_option(disable_scripting, "Disable scripting by default", "disable-scripting");
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
args_parser.add_option(disable_sql_database, "Disable SQL database", "disable-sql-database");
LibWebView+UI: Allow debugging any helper process This removes the --debug-web-content flag, and replaces it with a --debug-process=<process-name> flag. For example: ladybird --debug-process=WebContent ladybird --debug-process=RequestServer This allows attaching gdb to any helper process.
2024-08-01 07:03:03 -04:00
args_parser.add_option(debug_process, "Wait for a debugger to attach to the given process name (WebContent, RequestServer, etc.)", "debug-process", 0, "process-name");
LibWebView+UI: Allow profiling any helper process This removes the --enable-callgrind-profiling flag, and replaces it with a --profile-process=<process-name> flag. For example: ladybird --profile-process=WebContent ladybird --profile-process=RequestServer This allows profiling any helper process with callgrind.
2024-08-01 07:13:09 -04:00
args_parser.add_option(profile_process, "Enable callgrind profiling of the given process name (WebContent, RequestServer, etc.)", "profile-process", 0, "process-name");
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
args_parser.add_option(webdriver_content_ipc_path, "Path to WebDriver IPC for WebContent", "webdriver-content-path", 0, "path", Core::ArgsParser::OptionHideMode::CommandLineAndMarkdown);
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
args_parser.add_option(layout_test_mode, "Enable layout test mode", "layout-test-mode");
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
args_parser.add_option(log_all_js_exceptions, "Log all JavaScript exceptions", "log-all-js-exceptions");
LibWebView+WebContent: Add a command-line flag to disable site isolation
2025-03-11 19:25:34 -04:00
args_parser.add_option(disable_site_isolation, "Disable site isolation", "disable-site-isolation");
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
args_parser.add_option(enable_idl_tracing, "Enable IDL tracing", "enable-idl-tracing");
LibWebView: Enable HTTP cache by default The HTTP cache is now stable enough that we can ask more people to help us testing it. So let's turn it on by default! It can be turned off with --disable-http-cache if needed.
2025-09-07 22:40:15 +02:00
args_parser.add_option(disable_http_cache, "Disable HTTP cache", "disable-http-cache");
UI: Add an option to enable autoplay globally
2024-09-22 23:12:36 +01:00
args_parser.add_option(enable_autoplay, "Enable multimedia autoplay", "enable-autoplay");
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
args_parser.add_option(expose_internals_object, "Expose internals object", "expose-internals-object");
LibWebView+WebContent: Add a `--force-cpu-painting` option This option forces Skia to use the CPU backend rather than using the GPU.
2024-08-01 18:49:24 +01:00
args_parser.add_option(force_cpu_painting, "Force CPU painting", "force-cpu-painting");
Ladybird+LibWeb+LibGfx: Add option to force use of fontconfig This allows us to get identical metrics on macOS and Linux. Without this, Skia will use CoreText on macOS and give us slightly different text metrics. That causes layout tests to be slightly different on different platforms, which is a huge headache. So let's not do that. You can now launch Ladybird and headless-browser with --force-fontconfig to load fonts through fontconfig. Tests run in this mode by default.
2024-08-19 20:35:49 +02:00
args_parser.add_option(force_fontconfig, "Force using fontconfig for font loading", "force-fontconfig");
LibWebView: Add a browser flag to collect garbage after each allocation
2024-10-31 11:06:01 -04:00
args_parser.add_option(collect_garbage_on_every_allocation, "Collect garbage after every JS heap allocation", "collect-garbage-on-every-allocation", 'g');
LibWebView: Add an option to disable painting viewport scrollbars
2024-12-16 11:23:10 +00:00
args_parser.add_option(disable_scrollbar_painting, "Don't paint horizontal or vertical scrollbars on the main viewport", "disable-scrollbar-painting");
LibDNS+LibWeb+Ladybird+RequestServer: Let there be DNS over TLS This commit adds our own DNS resolver, with the aim of implementing DoT (and eventually DoH, maybe even DNSSEC etc.)
2024-11-01 23:53:43 +01:00
args_parser.add_option(dns_server_address, "Set the DNS server address", "dns-server", 0, "host|address");
args_parser.add_option(dns_server_port, "Set the DNS server port", "dns-port", 0, "port (default: 53 or 853 if --dot)");
args_parser.add_option(use_dns_over_tls, "Use DNS over TLS", "dot");
LibWebView+RequestSever: Wire up a validate-DNSSEC setting option to RS
2025-05-13 12:34:55 +02:00
args_parser.add_option(validate_dnssec_locally, "Validate DNSSEC locally", "dnssec");
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
LibWebView+UI: Launch the DevTools server if --devtools is specified This replaces the --devtools-port flag with a --devtools flag, which optionally accepts a port. If the --devtools flag is set, we will now automatically launch the DevTools server.
2025-07-02 12:42:53 -04:00
args_parser.add_option(Core::ArgsParser::Option {
.argument_mode = Core::ArgsParser::OptionArgumentMode::Optional,
.help_string = "Enable the Firefox DevTools server, with an optional port",
.long_name = "devtools",
.value_name = "port",
.accept_value = [&](StringView value) {
if (value.is_empty())
devtools_port = WebView::default_devtools_port;
else
devtools_port = value.to_number<u16>();
return devtools_port.has_value();
},
});
LibWebView: Add a command line option to override the User-Agent This commit just adds a command line option to case-insensitively accept a User-Agent name to use as the UA override. The UIs will individually need to make use of this option.
2024-08-28 10:26:11 -04:00
args_parser.add_option(Core::ArgsParser::Option {
.argument_mode = Core::ArgsParser::OptionArgumentMode::Required,
.help_string = "Name of the User-Agent preset to use in place of the default User-Agent",
.long_name = "user-agent-preset",
.value_name = "name",
.accept_value = [&](StringView value) {
user_agent_preset = normalize_user_agent_name(value);
return user_agent_preset.has_value();
},
});
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
create_platform_arguments(args_parser);
LibWebView+UI: Do not create a QApplication in headless mode This is causing errors on the WPT runner, which does not have a display output. To do this requires shuffling around the Main::Arguments struct, as we now need access to it from overridden WebView::Application methods after construction.
2025-06-10 14:56:24 -04:00
args_parser.parse(m_arguments);
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
LibWebView: Disable persisted SQL storage when forcing new UI processes We very much assume that the SQL storage backend runs in a singleton process. When this is not the case, and multiple UI processes try to write to the database at the same time, one of them will fail. Since --force-new-process is a testing mode flag, let's just disable the SQL backend when that flag is present.
2024-09-18 13:36:45 -04:00
// Our persisted SQL storage assumes it runs in a singleton process. If we have multiple UI processes accessing
// the same underlying database, one of them is likely to fail.
if (force_new_process)
disable_sql_database = true;
LibDNS+LibWeb+Ladybird+RequestServer: Let there be DNS over TLS This commit adds our own DNS resolver, with the aim of implementing DoT (and eventually DoH, maybe even DNSSEC etc.)
2024-11-01 23:53:43 +01:00
if (!dns_server_port.has_value())
dns_server_port = use_dns_over_tls ? 853 : 53;
LibWebView+UI: Allow debugging any helper process This removes the --debug-web-content flag, and replaces it with a --debug-process=<process-name> flag. For example: ladybird --debug-process=WebContent ladybird --debug-process=RequestServer This allows attaching gdb to any helper process.
2024-08-01 07:03:03 -04:00
Optional<ProcessType> debug_process_type;
LibWebView+UI: Allow profiling any helper process This removes the --enable-callgrind-profiling flag, and replaces it with a --profile-process=<process-name> flag. For example: ladybird --profile-process=WebContent ladybird --profile-process=RequestServer This allows profiling any helper process with callgrind.
2024-08-01 07:13:09 -04:00
Optional<ProcessType> profile_process_type;
LibWebView+UI: Allow debugging any helper process This removes the --debug-web-content flag, and replaces it with a --debug-process=<process-name> flag. For example: ladybird --debug-process=WebContent ladybird --debug-process=RequestServer This allows attaching gdb to any helper process.
2024-08-01 07:03:03 -04:00
if (debug_process.has_value())
debug_process_type = process_type_from_name(*debug_process);
LibWebView+UI: Allow profiling any helper process This removes the --enable-callgrind-profiling flag, and replaces it with a --profile-process=<process-name> flag. For example: ladybird --profile-process=WebContent ladybird --profile-process=RequestServer This allows profiling any helper process with callgrind.
2024-08-01 07:13:09 -04:00
if (profile_process.has_value())
profile_process_type = process_type_from_name(*profile_process);
LibWebView+UI: Allow debugging any helper process This removes the --debug-web-content flag, and replaces it with a --debug-process=<process-name> flag. For example: ladybird --debug-process=WebContent ladybird --debug-process=RequestServer This allows attaching gdb to any helper process.
2024-08-01 07:03:03 -04:00
LibWebView: Disable site isolation and spare processes when debugging These features make it difficult to debug a single WebContent instance.
2025-03-14 08:59:38 -04:00
// Disable site isolation when debugging WebContent. Otherwise, the process swap may interfere with the gdb session.
if (debug_process_type == ProcessType::WebContent)
disable_site_isolation = true;
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 16:56:52 -04:00
m_browser_options = {
LibWebView+UI: Introduce a persistent settings object This adds a WebView::Settings class to own persistent browser settings. In this first pass, it now owns the new tab page URL and search engine settings. For simplicitly, we currently use a JSON format for these settings. They are stored alongside the cookie database. As of this commit, the saved JSON will have the form: { "newTabPageURL": "about:blank", "searchEngine": { "name": "Google" } } (The search engine is an object to allow room for a future patch to implement custom search engine URLs.) For Qt, this replaces the management of these particular settings in the Qt settings UI. We will have an internal browser page to control these settings instead. In the future, we will want to port all settings to this new class. We will also want to allow UI-specific settings (such as whether the hamburger menu is displayed in Qt).
2025-03-20 12:59:44 -04:00
.urls = sanitize_urls(raw_urls, m_settings.new_tab_page_url()),
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
.raw_urls = move(raw_urls),
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
.headless_mode = headless_mode,
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
.certificates = move(certificates),
.new_window = new_window ? NewWindow::Yes : NewWindow::No,
.force_new_process = force_new_process ? ForceNewProcess::Yes : ForceNewProcess::No,
.allow_popups = allow_popups ? AllowPopups::Yes : AllowPopups::No,
UI: Add the `--disable-scripting` option to disable scripting by default
2024-09-04 07:13:40 +01:00
.disable_scripting = disable_scripting ? DisableScripting::Yes : DisableScripting::No,
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
.disable_sql_database = disable_sql_database ? DisableSQLDatabase::Yes : DisableSQLDatabase::No,
LibWebView+UI: Allow debugging any helper process This removes the --debug-web-content flag, and replaces it with a --debug-process=<process-name> flag. For example: ladybird --debug-process=WebContent ladybird --debug-process=RequestServer This allows attaching gdb to any helper process.
2024-08-01 07:03:03 -04:00
.debug_helper_process = move(debug_process_type),
LibWebView+UI: Allow profiling any helper process This removes the --enable-callgrind-profiling flag, and replaces it with a --profile-process=<process-name> flag. For example: ladybird --profile-process=WebContent ladybird --profile-process=RequestServer This allows profiling any helper process with callgrind.
2024-08-01 07:13:09 -04:00
.profile_helper_process = move(profile_process_type),
LibDNS+LibWeb+Ladybird+RequestServer: Let there be DNS over TLS This commit adds our own DNS resolver, with the aim of implementing DoT (and eventually DoH, maybe even DNSSEC etc.)
2024-11-01 23:53:43 +01:00
.dns_settings = (dns_server_address.has_value()
LibWebView+RequestServer: Add some UI for DNS settings
2025-04-08 03:56:35 +02:00
? Optional<DNSSettings> { use_dns_over_tls
LibWebView+RequestSever: Wire up a validate-DNSSEC setting option to RS
2025-05-13 12:34:55 +02:00
? DNSSettings(DNSOverTLS(dns_server_address.release_value(), *dns_server_port, validate_dnssec_locally))
: DNSSettings(DNSOverUDP(dns_server_address.release_value(), *dns_server_port, validate_dnssec_locally)) }
LibWebView+RequestServer: Add some UI for DNS settings
2025-04-08 03:56:35 +02:00
: OptionalNone()),
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
.devtools_port = devtools_port,
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
};
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
if (window_width.has_value())
m_browser_options.window_width = *window_width;
if (window_height.has_value())
m_browser_options.window_height = *window_height;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
if (webdriver_content_ipc_path.has_value())
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 16:56:52 -04:00
m_browser_options.webdriver_content_ipc_path = *webdriver_content_ipc_path;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
m_web_content_options = {
LibWebView+UI: Do not create a QApplication in headless mode This is causing errors on the WPT runner, which does not have a display output. To do this requires shuffling around the Main::Arguments struct, as we now need access to it from overridden WebView::Application methods after construction.
2025-06-10 14:56:24 -04:00
.command_line = MUST(String::join(' ', m_arguments.strings)),
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
.executable_path = MUST(String::from_byte_string(MUST(Core::System::current_executable_path()))),
LibWebView: Add a command line option to override the User-Agent This commit just adds a command line option to case-insensitively accept a User-Agent name to use as the UA override. The UIs will individually need to make use of this option.
2024-08-28 10:26:11 -04:00
.user_agent_preset = move(user_agent_preset),
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
.is_layout_test_mode = layout_test_mode ? IsLayoutTestMode::Yes : IsLayoutTestMode::No,
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
.log_all_js_exceptions = log_all_js_exceptions ? LogAllJSExceptions::Yes : LogAllJSExceptions::No,
LibWebView+WebContent: Add a command-line flag to disable site isolation
2025-03-11 19:25:34 -04:00
.disable_site_isolation = disable_site_isolation ? DisableSiteIsolation::Yes : DisableSiteIsolation::No,
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
.enable_idl_tracing = enable_idl_tracing ? EnableIDLTracing::Yes : EnableIDLTracing::No,
LibWebView: Enable HTTP cache by default The HTTP cache is now stable enough that we can ask more people to help us testing it. So let's turn it on by default! It can be turned off with --disable-http-cache if needed.
2025-09-07 22:40:15 +02:00
.enable_http_cache = disable_http_cache ? EnableHTTPCache::No : EnableHTTPCache::Yes,
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
.expose_internals_object = expose_internals_object ? ExposeInternalsObject::Yes : ExposeInternalsObject::No,
LibWebView+WebContent: Add a `--force-cpu-painting` option This option forces Skia to use the CPU backend rather than using the GPU.
2024-08-01 18:49:24 +01:00
.force_cpu_painting = force_cpu_painting ? ForceCPUPainting::Yes : ForceCPUPainting::No,
Ladybird+LibWeb+LibGfx: Add option to force use of fontconfig This allows us to get identical metrics on macOS and Linux. Without this, Skia will use CoreText on macOS and give us slightly different text metrics. That causes layout tests to be slightly different on different platforms, which is a huge headache. So let's not do that. You can now launch Ladybird and headless-browser with --force-fontconfig to load fonts through fontconfig. Tests run in this mode by default.
2024-08-19 20:35:49 +02:00
.force_fontconfig = force_fontconfig ? ForceFontconfig::Yes : ForceFontconfig::No,
UI: Add an option to enable autoplay globally
2024-09-22 23:12:36 +01:00
.enable_autoplay = enable_autoplay ? EnableAutoplay::Yes : EnableAutoplay::No,
LibWebView: Add a browser flag to collect garbage after each allocation
2024-10-31 11:06:01 -04:00
.collect_garbage_on_every_allocation = collect_garbage_on_every_allocation ? CollectGarbageOnEveryAllocation::Yes : CollectGarbageOnEveryAllocation::No,
LibWebView: Add an option to disable painting viewport scrollbars
2024-12-16 11:23:10 +00:00
.paint_viewport_scrollbars = disable_scrollbar_painting ? PaintViewportScrollbars::No : PaintViewportScrollbars::Yes,
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
};
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 16:56:52 -04:00
create_platform_options(m_browser_options, m_web_content_options);
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
initialize_actions();
LibWebView+UI: Move the database and cookie jar to WebView::Application The main motivator here was noticing that --disable-sql-database did not work with AppKit. Rather than re-implementing this there, move ownership of these classes to WebView::Application, so that each UI does not need to individually worry about it.
2024-09-05 18:19:51 -04:00
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
m_event_loop = create_platform_event_loop();
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 19:20:46 -04:00
TRY(launch_services());
return {};
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -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 Application::open_url_in_new_tab(URL::URL const& url, Web::HTML::ActivateTab activate_tab) const
{
if (auto view = open_blank_new_tab(activate_tab); view.has_value())
view->load(url);
}
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
static ErrorOr<NonnullRefPtr<WebContentClient>> create_web_content_client(Optional<ViewImplementation&> view)
{
auto request_server_socket = TRY(connect_new_request_server_client());
auto image_decoder_socket = TRY(connect_new_image_decoder_client());
if (view.has_value())
return WebView::launch_web_content_process(*view, move(image_decoder_socket), move(request_server_socket));
return WebView::launch_spare_web_content_process(move(image_decoder_socket), move(request_server_socket));
}
ErrorOr<NonnullRefPtr<WebContentClient>> Application::launch_web_content_process(ViewImplementation& view)
{
if (m_spare_web_content_process) {
auto web_content_client = m_spare_web_content_process.release_nonnull();
launch_spare_web_content_process();
web_content_client->assign_view({}, view);
return web_content_client;
}
launch_spare_web_content_process();
return create_web_content_client(view);
}
void Application::launch_spare_web_content_process()
{
LibWebView: Disable site isolation and spare processes when debugging These features make it difficult to debug a single WebContent instance.
2025-03-14 08:59:38 -04:00
// Disable spare processes when debugging WebContent. Otherwise, it breaks running `gdb attach -p $(pidof WebContent)`.
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 16:56:52 -04:00
if (browser_options().debug_helper_process == ProcessType::WebContent)
LibWebView: Disable site isolation and spare processes when debugging These features make it difficult to debug a single WebContent instance.
2025-03-14 08:59:38 -04:00
return;
LibWebView: Disable spare WebContent processes when profiling WebContent Each WebContent process will create a callgrind log file. Let's not log processes we are not interested in.
2025-05-08 08:08:34 -04:00
// Disable spare processes when profiling WebContent. This reduces callgrind logging we are not interested in.
if (browser_options().profile_helper_process == ProcessType::WebContent)
return;
LibWebView: Disable site isolation and spare processes when debugging These features make it difficult to debug a single WebContent instance.
2025-03-14 08:59:38 -04: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
if (m_has_queued_task_to_launch_spare_web_content_process)
return;
m_has_queued_task_to_launch_spare_web_content_process = true;
Core::deferred_invoke([this]() {
m_has_queued_task_to_launch_spare_web_content_process = false;
auto web_content_client = create_web_content_client({});
if (web_content_client.is_error()) {
dbgln("Unable to create spare web content client: {}", web_content_client.error());
return;
}
m_spare_web_content_process = web_content_client.release_value();
if (auto process = find_process(m_spare_web_content_process->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("(spare)"_utf16);
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
});
}
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
ErrorOr<void> Application::launch_services()
{
LibWebView: Defer creating services until after application init In particular, we need to defer creating the process manager until after we have decided whether or not to create a UI-specific event loop. If we create the process manager sooner, its event loop signal registration does not work, and we don't handle child processes exiting.
2025-06-11 07:32:37 -04:00
m_settings_observer = make<ApplicationSettingsObserver>();
m_process_manager = make<ProcessManager>();
m_process_manager->on_process_exited = [this](Process&& process) {
process_did_exit(move(process));
};
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
if (m_browser_options.disable_sql_database == DisableSQLDatabase::No) {
m_database = Database::create().release_value_but_fixme_should_propagate_errors();
m_cookie_jar = CookieJar::create(*m_database).release_value_but_fixme_should_propagate_errors();
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
m_storage_jar = StorageJar::create(*m_database).release_value_but_fixme_should_propagate_errors();
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
} else {
m_cookie_jar = CookieJar::create();
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
m_storage_jar = StorageJar::create();
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
}
LibWebView: Defer creating services until after application init In particular, we need to defer creating the process manager until after we have decided whether or not to create a UI-specific event loop. If we create the process manager sooner, its event loop signal registration does not work, and we don't handle child processes exiting.
2025-06-11 07:32:37 -04:00
// No need to monitor the system time zone if the TZ environment variable is set, as it overrides system preferences.
if (!Core::Environment::has("TZ"sv)) {
if (auto time_zone_watcher = Core::TimeZoneWatcher::create(); time_zone_watcher.is_error()) {
warnln("Unable to monitor system time zone: {}", time_zone_watcher.error());
} else {
m_time_zone_watcher = time_zone_watcher.release_value();
m_time_zone_watcher->on_time_zone_changed = []() {
WebContentClient::for_each_client([&](WebView::WebContentClient& client) {
client.async_system_time_zone_changed();
return IterationDecision::Continue;
});
};
}
}
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
TRY(launch_request_server());
TRY(launch_image_decoder_server());
LibWebView+UI: Launch the DevTools server if --devtools is specified This replaces the --devtools-port flag with a --devtools flag, which optionally accepts a port. If the --devtools flag is set, we will now automatically launch the DevTools server.
2025-07-02 12:42:53 -04:00
if (m_browser_options.devtools_port.has_value())
TRY(launch_devtools_server());
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
return {};
}
ErrorOr<void> Application::launch_request_server()
{
LibWebView+UI: Acquire the paths to helper processes inside LibWebView We no longer need to acquire these paths from the UI and pass them into LibWebView - we can figure out these paths internally.
2024-11-13 16:04:33 -05:00
m_request_server_client = TRY(launch_request_server_process());
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 12:37:05 -04:00
LibWebView: Gracefully handle RequestServer death This works exactly the same as ImageDecoder death handling.
2025-08-09 13:08:20 -04:00
m_request_server_client->on_request_server_died = [this]() {
m_request_server_client = nullptr;
if (Core::EventLoop::current().was_exit_requested())
return;
if (auto result = launch_request_server(); result.is_error()) {
warnln("\033[31;1mUnable to launch replacement RequestServer: {}\033[0m", result.error());
VERIFY_NOT_REACHED();
}
auto client_count = WebContentClient::client_count();
auto request_server_sockets = m_request_server_client->send_sync_but_allow_failure<Messages::RequestServer::ConnectNewClients>(client_count);
if (!request_server_sockets || request_server_sockets->sockets().is_empty()) {
warnln("\033Failed to connect {} new clients to ImageDecoder\033[0m", client_count);
VERIFY_NOT_REACHED();
}
WebContentClient::for_each_client([sockets = request_server_sockets->take_sockets()](WebContentClient& client) mutable {
client.async_connect_to_request_server(sockets.take_last());
return IterationDecision::Continue;
});
};
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 12:37:05 -04:00
if (m_browser_options.dns_settings.has_value())
m_settings.set_dns_settings(m_browser_options.dns_settings.value(), true);
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
return {};
}
ErrorOr<void> Application::launch_image_decoder_server()
{
LibWebView+UI: Acquire the paths to helper processes inside LibWebView We no longer need to acquire these paths from the UI and pass them into LibWebView - we can figure out these paths internally.
2024-11-13 16:04:33 -05:00
m_image_decoder_client = TRY(launch_image_decoder_process());
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
m_image_decoder_client->on_death = [this]() {
m_image_decoder_client = nullptr;
LibWebView: Ignore ImageDecoder death during process shutdown
2025-08-09 12:21:21 -04:00
if (Core::EventLoop::current().was_exit_requested())
return;
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
if (auto result = launch_image_decoder_server(); result.is_error()) {
dbgln("Failed to restart image decoder: {}", result.error());
VERIFY_NOT_REACHED();
}
auto client_count = WebContentClient::client_count();
auto new_sockets = m_image_decoder_client->send_sync_but_allow_failure<Messages::ImageDecoderServer::ConnectNewClients>(client_count);
if (!new_sockets || new_sockets->sockets().is_empty()) {
dbgln("Failed to connect {} new clients to ImageDecoder", client_count);
VERIFY_NOT_REACHED();
}
WebContentClient::for_each_client([sockets = new_sockets->take_sockets()](WebContentClient& client) mutable {
client.async_connect_to_image_decoder(sockets.take_last());
return IterationDecision::Continue;
});
};
return {};
}
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
ErrorOr<void> Application::launch_devtools_server()
{
LibWebView: Change the DevTools server to be a runtime-enabled feature
2025-03-15 10:09:45 -04:00
VERIFY(!m_devtools);
LibWebView+UI: Launch the DevTools server if --devtools is specified This replaces the --devtools-port flag with a --devtools flag, which optionally accepts a port. If the --devtools flag is set, we will now automatically launch the DevTools server.
2025-07-02 12:42:53 -04:00
if (!m_browser_options.devtools_port.has_value())
m_browser_options.devtools_port = WebView::default_devtools_port;
m_devtools = TRY(DevTools::DevToolsServer::create(*this, *m_browser_options.devtools_port));
LibWebView+UI: Generate action to enable/disable DevTools
2025-09-17 10:03:01 -04:00
on_devtools_enabled();
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
return {};
}
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
static NonnullRefPtr<Core::Timer> load_page_for_screenshot_and_exit(Core::EventLoop& event_loop, HeadlessWebView& view, URL::URL const& url, int screenshot_timeout)
{
outln("Taking screenshot after {} seconds", screenshot_timeout);
auto timer = Core::Timer::create_single_shot(
screenshot_timeout * 1000,
[&]() {
view.take_screenshot(ViewImplementation::ScreenshotType::Full)
->when_resolved([&event_loop](auto const& path) {
outln("Saved screenshot to: {}", path);
event_loop.quit(0);
})
.when_rejected([&event_loop](auto const& error) {
warnln("Unable to take screenshot: {}", error);
event_loop.quit(0);
});
});
view.load(url);
timer->start();
return timer;
}
static void load_page_for_info_and_exit(Core::EventLoop& event_loop, HeadlessWebView& view, URL::URL const& url, WebView::PageInfoType type)
{
view.on_load_finish = [&view, &event_loop, url, type](auto const& loaded_url) {
if (!url.equals(loaded_url, URL::ExcludeFragment::Yes))
return;
view.request_internal_page_info(type)->when_resolved([&event_loop](auto const& text) {
outln("{}", text);
event_loop.quit(0);
});
};
view.load(url);
}
ErrorOr<int> Application::execute()
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
{
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
OwnPtr<HeadlessWebView> view;
RefPtr<Core::Timer> screenshot_timer;
if (m_browser_options.headless_mode.has_value()) {
auto theme_path = LexicalPath::join(WebView::s_ladybird_resource_root, "themes"sv, "Default.ini"sv);
auto theme = TRY(Gfx::load_system_theme(theme_path.string()));
view = HeadlessWebView::create(move(theme), { m_browser_options.window_width, m_browser_options.window_height });
if (!m_browser_options.webdriver_content_ipc_path.has_value()) {
if (m_browser_options.urls.size() != 1)
return Error::from_string_literal("Headless mode currently only supports exactly one URL");
switch (*m_browser_options.headless_mode) {
case HeadlessMode::Screenshot:
screenshot_timer = load_page_for_screenshot_and_exit(*m_event_loop, *view, m_browser_options.urls.first(), 1);
break;
case HeadlessMode::LayoutTree:
load_page_for_info_and_exit(*m_event_loop, *view, m_browser_options.urls.first(), WebView::PageInfoType::LayoutTree | WebView::PageInfoType::PaintTree);
break;
case HeadlessMode::Text:
load_page_for_info_and_exit(*m_event_loop, *view, m_browser_options.urls.first(), WebView::PageInfoType::Text);
break;
case HeadlessMode::Test:
VERIFY_NOT_REACHED();
}
}
}
LibWebView: Remove `m_in_shutdown` in favor of event loop's exit request
2025-08-18 00:42:15 +02:00
return m_event_loop->exec();
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
}
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
NonnullOwnPtr<Core::EventLoop> Application::create_platform_event_loop()
{
return make<Core::EventLoop>();
}
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
void Application::add_child_process(WebView::Process&& process)
{
LibWebView: Defer creating services until after application init In particular, we need to defer creating the process manager until after we have decided whether or not to create a UI-specific event loop. If we create the process manager sooner, its event loop signal registration does not work, and we don't handle child processes exiting.
2025-06-11 07:32:37 -04:00
m_process_manager->add_process(move(process));
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 defined(AK_OS_MACH)
void Application::set_process_mach_port(pid_t pid, Core::MachPort&& port)
{
LibWebView: Defer creating services until after application init In particular, we need to defer creating the process manager until after we have decided whether or not to create a UI-specific event loop. If we create the process manager sooner, its event loop signal registration does not work, and we don't handle child processes exiting.
2025-06-11 07:32:37 -04:00
m_process_manager->set_process_mach_port(pid, move(port));
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
}
#endif
Optional<Process&> Application::find_process(pid_t pid)
{
LibWebView: Defer creating services until after application init In particular, we need to defer creating the process manager until after we have decided whether or not to create a UI-specific event loop. If we create the process manager sooner, its event loop signal registration does not work, and we don't handle child processes exiting.
2025-06-11 07:32:37 -04:00
return m_process_manager->find_process(pid);
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
}
void Application::process_did_exit(Process&& process)
{
LibWebView: Remove `m_in_shutdown` in favor of event loop's exit request
2025-08-18 00:42:15 +02:00
if (m_event_loop->was_exit_requested())
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
return;
dbgln_if(WEBVIEW_PROCESS_DEBUG, "Process {} died, type: {}", process.pid(), process_name_from_type(process.type()));
switch (process.type()) {
case ProcessType::ImageDecoder:
if (auto client = process.client<ImageDecoderClient::Client>(); client.has_value()) {
dbgln_if(WEBVIEW_PROCESS_DEBUG, "Restart ImageDecoder process");
if (auto on_death = move(client->on_death)) {
on_death();
}
}
break;
case ProcessType::RequestServer:
LibWebView: Gracefully handle RequestServer death This works exactly the same as ImageDecoder death handling.
2025-08-09 13:08:20 -04:00
if (auto client = process.client<Requests::RequestClient>(); client.has_value()) {
dbgln_if(WEBVIEW_PROCESS_DEBUG, "Restart request server");
if (auto on_request_server_died = move(client->on_request_server_died))
on_request_server_died();
}
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
break;
case ProcessType::WebContent:
if (auto client = process.client<WebContentClient>(); client.has_value()) {
dbgln_if(WEBVIEW_PROCESS_DEBUG, "Restart WebContent process");
if (auto on_web_content_process_crash = move(client->on_web_content_process_crash))
on_web_content_process_crash();
}
break;
case ProcessType::WebWorker:
dbgln_if(WEBVIEW_PROCESS_DEBUG, "WebWorker {} died, not sure what to do.", process.pid());
break;
LibWebView: Rename the Chrome process type to Browser
2025-03-15 17:10:13 -04:00
case ProcessType::Browser:
dbgln("Invalid process type to be dying: Browser");
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
VERIFY_NOT_REACHED();
}
}
LibWebView: Add facilities to ask the user for a download directory If the Downloads directory exists, we will use it (note that this will respect the XDG_DOWNLOAD_DIR environment variable). Otherwise, we will ask the UI layer to retrieve a download directory from the user. This directory is not saved, so it will be re-prompted every time. Once a proper settings UI is complete, we will of course integrate with that for persistent settings.
2024-08-28 15:29:51 -04:00
ErrorOr<LexicalPath> Application::path_for_downloaded_file(StringView file) const
{
auto downloads_directory = Core::StandardPaths::downloads_directory();
if (!FileSystem::is_directory(downloads_directory)) {
LibWebView: Show a better error for invalid download dir in headless Previously if the directory returned by `downloads_directory()` didn't exist (or wasn't a directory) when taking a screnshot in headless mode we try to ask the user for the download directory and fail with the unhelpful error: QWidget: Must construct a QApplication before a QWidget
2025-09-16 11:16:53 +12:00
if (browser_options().headless_mode.has_value()) {
dbgln("Unable to ask user for download folder in headless mode, please ensure {} is a directory or use the XDG_DOWNLOAD_DIR environment variable to set a new download directory", downloads_directory);
return Error::from_errno(ENOENT);
}
LibWebView: Add facilities to ask the user for a download directory If the Downloads directory exists, we will use it (note that this will respect the XDG_DOWNLOAD_DIR environment variable). Otherwise, we will ask the UI layer to retrieve a download directory from the user. This directory is not saved, so it will be re-prompted every time. Once a proper settings UI is complete, we will of course integrate with that for persistent settings.
2024-08-28 15:29:51 -04:00
auto maybe_downloads_directory = ask_user_for_download_folder();
if (!maybe_downloads_directory.has_value())
return Error::from_errno(ECANCELED);
downloads_directory = maybe_downloads_directory.release_value();
}
if (!FileSystem::is_directory(downloads_directory))
return Error::from_errno(ENOENT);
return LexicalPath::join(downloads_directory, file);
}
LibWebView+UI: Extract some UI-specific displays to Application helpers This is preparation for moving application menus to LibWebView. We will need a way to display these dialogs from outside of the UI layer.
2025-09-04 08:53:57 -04:00
void Application::display_download_confirmation_dialog(StringView download_name, LexicalPath const& path) const
{
outln("{} saved to: {}", download_name, path);
}
void Application::display_error_dialog(StringView error_message) const
{
warnln("{}", error_message);
}
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
void Application::initialize_actions()
{
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 09:00:52 -04:00
auto debug_request = [this](auto request) {
return [this, request]() {
if (auto view = active_web_view(); view.has_value())
view->debug_request(request);
};
};
auto check = [](auto& action, auto request) {
return [&action, request]() {
ViewImplementation::for_each_view([checked = action->checked(), request](ViewImplementation& view) {
view.debug_request(request, checked ? "on"sv : "off"sv);
return IterationDecision::Continue;
});
};
};
auto add_spoofed_value = [](auto& menu, auto name, auto value, auto& cached_value, auto request) {
auto action = Action::create_checkable(name, ActionID::SpoofUserAgent, [value, &cached_value, request]() {
cached_value = value;
ViewImplementation::for_each_view([&](ViewImplementation& view) {
view.debug_request(request, cached_value);
view.debug_request("clear-cache"sv); // Clear the cache to ensure requests are re-done with the new value.
return IterationDecision::Continue;
});
});
action->set_checked(value == cached_value);
menu->add_action(move(action));
};
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
m_reload_action = Action::create("Reload"sv, ActionID::Reload, [this]() {
if (auto view = active_web_view(); view.has_value())
view->reload();
});
m_copy_selection_action = Action::create("Copy"sv, ActionID::CopySelection, [this]() {
if (auto view = active_web_view(); 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
insert_clipboard_entry({ view->selected_text(), "text/plain"_string });
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
});
m_paste_action = Action::create("Paste"sv, ActionID::Paste, [this]() {
if (auto view = active_web_view(); view.has_value())
view->paste_text_from_clipboard();
});
m_select_all_action = Action::create("Select All"sv, ActionID::SelectAll, [this]() {
if (auto view = active_web_view(); view.has_value())
view->select_all();
});
LibWebView+UI: Generate actions to open about: pages
2025-09-17 09:18:08 -04:00
m_open_about_page_action = Action::create("About Ladybird"sv, ActionID::OpenAboutPage, [this]() {
open_url_in_new_tab(URL::about_version(), Web::HTML::ActivateTab::Yes);
});
m_open_settings_page_action = Action::create("Settings"sv, ActionID::OpenSettingsPage, [this]() {
open_url_in_new_tab(URL::about_settings(), Web::HTML::ActivateTab::Yes);
});
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 09:00:52 -04:00
LibWebView+UI: Generate the zoom menu
2025-09-10 07:23:15 -04:00
m_zoom_menu = Menu::create_group("Zoom"sv);
m_zoom_menu->add_action(Action::create("Zoom In"sv, ActionID::ZoomIn, [this]() {
if (auto view = active_web_view(); view.has_value())
view->zoom_in();
}));
m_zoom_menu->add_action(Action::create("Zoom Out"sv, ActionID::ZoomOut, [this]() {
if (auto view = active_web_view(); view.has_value())
view->zoom_out();
}));
m_reset_zoom_action = Action::create("Reset Zoom"sv, ActionID::ResetZoom, [this]() {
if (auto view = active_web_view(); view.has_value())
view->reset_zoom();
});
m_zoom_menu->add_action(*m_reset_zoom_action);
LibWebView+UI: Generate the preferred color, contrast, and motion menus
2025-09-03 11:23:09 -04:00
auto set_color_scheme = [this](auto color_scheme) {
return [this, color_scheme]() {
m_color_scheme = color_scheme;
ViewImplementation::for_each_view([&](ViewImplementation& view) {
view.set_preferred_color_scheme(m_color_scheme);
return IterationDecision::Continue;
});
};
};
m_color_scheme_menu = Menu::create_group("Color Scheme"sv);
m_color_scheme_menu->add_action(Action::create_checkable("Auto"sv, ActionID::PreferredColorScheme, set_color_scheme(Web::CSS::PreferredColorScheme::Auto)));
m_color_scheme_menu->add_action(Action::create_checkable("Dark"sv, ActionID::PreferredColorScheme, set_color_scheme(Web::CSS::PreferredColorScheme::Dark)));
m_color_scheme_menu->add_action(Action::create_checkable("Light"sv, ActionID::PreferredColorScheme, set_color_scheme(Web::CSS::PreferredColorScheme::Light)));
m_color_scheme_menu->items().first().get<NonnullRefPtr<Action>>()->set_checked(true);
auto set_contrast = [this](auto contrast) {
return [this, contrast]() {
m_contrast = contrast;
ViewImplementation::for_each_view([&](ViewImplementation& view) {
view.set_preferred_contrast(m_contrast);
return IterationDecision::Continue;
});
};
};
m_contrast_menu = Menu::create_group("Contrast"sv);
m_contrast_menu->add_action(Action::create_checkable("Auto"sv, ActionID::PreferredContrast, set_contrast(Web::CSS::PreferredContrast::Auto)));
m_contrast_menu->add_action(Action::create_checkable("Less"sv, ActionID::PreferredContrast, set_contrast(Web::CSS::PreferredContrast::Less)));
m_contrast_menu->add_action(Action::create_checkable("More"sv, ActionID::PreferredContrast, set_contrast(Web::CSS::PreferredContrast::More)));
m_contrast_menu->add_action(Action::create_checkable("No Preference"sv, ActionID::PreferredContrast, set_contrast(Web::CSS::PreferredContrast::NoPreference)));
m_contrast_menu->items().first().get<NonnullRefPtr<Action>>()->set_checked(true);
auto set_motion = [this](auto motion) {
return [this, motion]() {
m_motion = motion;
ViewImplementation::for_each_view([&](ViewImplementation& view) {
view.set_preferred_motion(m_motion);
return IterationDecision::Continue;
});
};
};
m_motion_menu = Menu::create_group("Motion"sv);
m_motion_menu->add_action(Action::create_checkable("Auto"sv, ActionID::PreferredMotion, set_motion(Web::CSS::PreferredMotion::Auto)));
m_motion_menu->add_action(Action::create_checkable("Reduce"sv, ActionID::PreferredMotion, set_motion(Web::CSS::PreferredMotion::Reduce)));
m_motion_menu->add_action(Action::create_checkable("No Preference"sv, ActionID::PreferredMotion, set_motion(Web::CSS::PreferredMotion::NoPreference)));
m_motion_menu->items().first().get<NonnullRefPtr<Action>>()->set_checked(true);
LibWebView+UI: Generate the entire Inspect menu Now that all the actions in the Inspect menu are generated, we can generate the menu itself.
2025-09-17 10:22:23 -04:00
m_inspect_menu = Menu::create("Inspect"sv);
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 09:00:52 -04:00
LibWebView+UI: Generate the entire Inspect menu Now that all the actions in the Inspect menu are generated, we can generate the menu itself.
2025-09-17 10:22:23 -04:00
m_view_source_action = Action::create("View Source"sv, ActionID::ViewSource, [this]() {
if (auto view = active_web_view(); view.has_value())
view->get_source();
});
m_inspect_menu->add_action(*m_view_source_action);
m_inspect_menu->add_action(Action::create("Open Task Manager"sv, ActionID::OpenProcessesPage, [this]() {
open_url_in_new_tab(URL::about_processes(), Web::HTML::ActivateTab::Yes);
}));
m_toggle_devtools_action = Action::create("Enable DevTools"sv, ActionID::ToggleDevTools, [this]() {
if (auto result = toggle_devtools_enabled(); result.is_error())
display_error_dialog(MUST(String::formatted("Unable to start DevTools: {}", result.error())));
});
m_inspect_menu->add_action(*m_toggle_devtools_action);
m_debug_menu = Menu::create("Debug"sv);
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 09:00:52 -04:00
m_debug_menu->add_action(Action::create("Dump Session History Tree"sv, ActionID::DumpSessionHistoryTree, debug_request("dump-session-history"sv)));
m_debug_menu->add_action(Action::create("Dump DOM Tree"sv, ActionID::DumpDOMTree, debug_request("dump-dom-tree"sv)));
m_debug_menu->add_action(Action::create("Dump Layout Tree"sv, ActionID::DumpLayoutTree, debug_request("dump-layout-tree"sv)));
m_debug_menu->add_action(Action::create("Dump Paint Tree"sv, ActionID::DumpPaintTree, debug_request("dump-paint-tree"sv)));
m_debug_menu->add_action(Action::create("Dump Stacking Context Tree"sv, ActionID::DumpStackingContextTree, debug_request("dump-stacking-context-tree"sv)));
m_debug_menu->add_action(Action::create("Dump Display List"sv, ActionID::DumpDisplayList, debug_request("dump-display-list"sv)));
m_debug_menu->add_action(Action::create("Dump Style Sheets"sv, ActionID::DumpStyleSheets, debug_request("dump-style-sheets"sv)));
m_debug_menu->add_action(Action::create("Dump All Resolved Styles"sv, ActionID::DumpStyles, debug_request("dump-all-resolved-styles"sv)));
m_debug_menu->add_action(Action::create("Dump CSS Errors"sv, ActionID::DumpCSSErrors, debug_request("dump-all-css-errors"sv)));
m_debug_menu->add_action(Action::create("Dump Cookies"sv, ActionID::DumpCookies, [this]() { m_cookie_jar->dump_cookies(); }));
m_debug_menu->add_action(Action::create("Dump Local Storage"sv, ActionID::DumpLocalStorage, debug_request("dump-local-storage"sv)));
m_debug_menu->add_action(Action::create("Dump GC graph"sv, ActionID::DumpGCGraph, [this]() {
if (auto view = active_web_view(); view.has_value()) {
auto gc_graph_path = view->dump_gc_graph();
warnln("\033[33;1mDumped GC-graph into {}\033[0m", gc_graph_path);
}
}));
m_debug_menu->add_separator();
m_show_line_box_borders_action = Action::create_checkable("Show Line Box Borders"sv, ActionID::ShowLineBoxBorders, check(m_show_line_box_borders_action, "set-line-box-borders"sv));
m_debug_menu->add_action(*m_show_line_box_borders_action);
m_debug_menu->add_separator();
m_debug_menu->add_action(Action::create("Collect Garbage"sv, ActionID::CollectGarbage, debug_request("collect-garbage"sv)));
m_debug_menu->add_action(Action::create("Clear Cache"sv, ActionID::ClearCache, debug_request("clear-cache"sv)));
m_debug_menu->add_action(Action::create("Clear All Cookies"sv, ActionID::ClearCookies, [this]() { m_cookie_jar->clear_all_cookies(); }));
m_debug_menu->add_separator();
auto spoof_user_agent_menu = Menu::create_group("Spoof User Agent"sv);
m_user_agent_string = m_web_content_options.user_agent_preset.has_value()
? *WebView::user_agents.get(*m_web_content_options.user_agent_preset)
: Web::default_user_agent;
add_spoofed_value(spoof_user_agent_menu, "Disabled"sv, Web::default_user_agent, m_user_agent_string, "spoof-user-agent"sv);
for (auto const& user_agent : WebView::user_agents)
add_spoofed_value(spoof_user_agent_menu, user_agent.key, user_agent.value, m_user_agent_string, "spoof-user-agent"sv);
auto navigator_compatibility_mode_menu = Menu::create_group("Navigator Compatibility Mode"sv);
m_navigator_compatibility_mode = "chrome"sv;
add_spoofed_value(navigator_compatibility_mode_menu, "Chrome"sv, "chrome"sv, m_navigator_compatibility_mode, "navigator-compatibility-mode"sv);
add_spoofed_value(navigator_compatibility_mode_menu, "Gecko"sv, "gecko"sv, m_navigator_compatibility_mode, "navigator-compatibility-mode"sv);
add_spoofed_value(navigator_compatibility_mode_menu, "WebKit"sv, "webkit"sv, m_navigator_compatibility_mode, "navigator-compatibility-mode"sv);
m_debug_menu->add_submenu(move(spoof_user_agent_menu));
m_debug_menu->add_submenu(move(navigator_compatibility_mode_menu));
m_debug_menu->add_separator();
m_enable_scripting_action = Action::create_checkable("Enable Scripting"sv, ActionID::EnableScripting, check(m_enable_scripting_action, "scripting"sv));
m_enable_scripting_action->set_checked(m_browser_options.disable_scripting == WebView::DisableScripting::No);
m_debug_menu->add_action(*m_enable_scripting_action);
m_enable_content_filtering_action = Action::create_checkable("Enable Content Filtering"sv, ActionID::EnableContentFiltering, check(m_enable_content_filtering_action, "content-filtering"sv));
m_enable_content_filtering_action->set_checked(true);
m_debug_menu->add_action(*m_enable_content_filtering_action);
m_block_pop_ups_action = Action::create_checkable("Block Pop-ups"sv, ActionID::BlockPopUps, check(m_block_pop_ups_action, "block-pop-ups"sv));
m_block_pop_ups_action->set_checked(m_browser_options.allow_popups == AllowPopups::No);
m_debug_menu->add_action(*m_block_pop_ups_action);
}
void Application::apply_view_options(Badge<ViewImplementation>, ViewImplementation& view)
{
LibWebView+UI: Generate the preferred color, contrast, and motion menus
2025-09-03 11:23:09 -04:00
view.set_preferred_color_scheme(m_color_scheme);
view.set_preferred_contrast(m_contrast);
view.set_preferred_motion(m_motion);
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 09:00:52 -04:00
view.debug_request("set-line-box-borders"sv, m_show_line_box_borders_action->checked() ? "on"sv : "off"sv);
view.debug_request("scripting"sv, m_enable_scripting_action->checked() ? "on"sv : "off"sv);
view.debug_request("content-filtering"sv, m_enable_content_filtering_action->checked() ? "on"sv : "off"sv);
view.debug_request("block-pop-ups"sv, m_block_pop_ups_action->checked() ? "on"sv : "off"sv);
view.debug_request("spoof-user-agent"sv, m_user_agent_string);
view.debug_request("navigator-compatibility-mode"sv, m_navigator_compatibility_mode);
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
}
LibWebView+UI: Generate action to enable/disable DevTools
2025-09-17 10:03:01 -04:00
ErrorOr<void> Application::toggle_devtools_enabled()
LibWebView: Change the DevTools server to be a runtime-enabled feature
2025-03-15 10:09:45 -04:00
{
if (m_devtools) {
m_devtools.clear();
LibWebView+UI: Generate action to enable/disable DevTools
2025-09-17 10:03:01 -04:00
on_devtools_disabled();
} else {
TRY(launch_devtools_server());
LibWebView: Change the DevTools server to be a runtime-enabled feature
2025-03-15 10:09:45 -04:00
}
LibWebView+UI: Generate action to enable/disable DevTools
2025-09-17 10:03:01 -04:00
return {};
}
void Application::on_devtools_enabled() const
{
m_toggle_devtools_action->set_text("Disable DevTools"sv);
}
void Application::on_devtools_disabled() const
{
m_toggle_devtools_action->set_text("Enable DevTools"sv);
LibWebView: Change the DevTools server to be a runtime-enabled feature
2025-03-15 10:09:45 -04:00
}
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
void Application::refresh_tab_list()
{
if (!m_devtools)
return;
m_devtools->refresh_tab_list();
}
Vector<DevTools::TabDescription> Application::tab_list() const
{
Vector<DevTools::TabDescription> tabs;
ViewImplementation::for_each_view([&](ViewImplementation& view) {
LibWeb+LibWebView+WebContent+UI: Port the document title to UTF-16
2025-07-28 16:51:01 -04:00
tabs.empend(view.view_id(), view.title().to_utf8(), view.url().to_string());
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
return IterationDecision::Continue;
});
return tabs;
}
Vector<DevTools::CSSProperty> Application::css_property_list() const
{
Vector<DevTools::CSSProperty> property_list;
for (auto i = to_underlying(Web::CSS::first_property_id); i <= to_underlying(Web::CSS::last_property_id); ++i) {
auto property_id = static_cast<Web::CSS::PropertyID>(i);
DevTools::CSSProperty property;
LibDevTools+LibWebView: Port DevTools to String
2025-02-19 09:28:02 -05:00
property.name = Web::CSS::string_from_property_id(property_id).to_string();
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
property.is_inherited = Web::CSS::is_inherited_property(property_id);
property_list.append(move(property));
}
return property_list;
}
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 16:22:12 -05:00
void Application::inspect_tab(DevTools::TabDescription const& description, OnTabInspectionComplete on_complete) const
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value()) {
on_complete(Error::from_string_literal("Unable to locate tab"));
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
view->on_received_dom_tree = [&view = *view, on_complete = move(on_complete)](JsonObject dom_tree) {
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
view.on_received_dom_tree = nullptr;
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
on_complete(move(dom_tree));
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
};
view->inspect_dom_tree();
}
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 Application::listen_for_dom_properties(DevTools::TabDescription const& description, OnDOMNodePropertiesReceived on_dom_node_properties_received) const
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 16:22:12 -05:00
{
auto view = ViewImplementation::find_view_by_id(description.id);
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 (!view.has_value())
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 16:22:12 -05:00
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
view->on_received_dom_node_properties = move(on_dom_node_properties_received);
}
LibDevTools+LibWebView: Avoid dependence on LibWebView from LibDevTools LibDevTools was implicitly including generated IPC endpoints from LibWebView. This is not a dependency declared in the CMakeLists.txt. So updates to the IPC file might not have caused the endpoint header to be regenerated by the time LibDevTools is compiled, resulting in a build error. This patch removes that implicit dependency entirely.
2025-02-26 17:23:10 -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
void Application::stop_listening_for_dom_properties(DevTools::TabDescription const& description) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
view->on_received_dom_node_properties = nullptr;
}
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
void Application::inspect_dom_node(DevTools::TabDescription const& description, DOMNodeProperties::Type property_type, Web::UniqueNodeID node_id, Optional<Web::CSS::PseudoElement> pseudo_element) const
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
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 16:22:12 -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
view->inspect_dom_node(node_id, property_type, pseudo_element);
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 16:22:12 -05:00
}
void Application::clear_inspected_dom_node(DevTools::TabDescription const& description) const
{
if (auto view = ViewImplementation::find_view_by_id(description.id); view.has_value())
view->clear_inspected_dom_node();
}
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
void Application::highlight_dom_node(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, Optional<Web::CSS::PseudoElement> pseudo_element) const
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 16:22:12 -05:00
{
if (auto view = ViewImplementation::find_view_by_id(description.id); view.has_value())
view->highlight_dom_node(node_id, pseudo_element);
}
void Application::clear_highlighted_dom_node(DevTools::TabDescription const& description) const
{
if (auto view = ViewImplementation::find_view_by_id(description.id); view.has_value())
view->clear_highlighted_dom_node();
}
LibDevTools+LibWebView: Inform the DevTools client about DOM mutations
2025-03-06 19:56:03 -05:00
void Application::listen_for_dom_mutations(DevTools::TabDescription const& description, OnDOMMutationReceived on_dom_mutation_received) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
view->on_dom_mutation_received = move(on_dom_mutation_received);
view->set_listen_for_dom_mutations(true);
}
void Application::stop_listening_for_dom_mutations(DevTools::TabDescription const& description) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
view->on_dom_mutation_received = nullptr;
view->set_listen_for_dom_mutations(false);
}
LibDevTools+LibWebView: Implement requests to edit DOM node text
2025-03-06 19:56:40 -05:00
template<typename Edit>
static void edit_dom_node(DevTools::TabDescription const& description, Application::OnDOMNodeEditComplete on_complete, Edit&& edit)
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value()) {
on_complete(Error::from_string_literal("Unable to locate tab"));
return;
}
LibWeb: Fix typos - act II
2025-04-07 10:46:22 +00:00
view->on_finished_editing_dom_node = [&view = *view, on_complete = move(on_complete)](auto node_id) {
view.on_finished_editing_dom_node = nullptr;
LibDevTools+LibWebView: Implement requests to edit DOM node text
2025-03-06 19:56:40 -05:00
if (node_id.has_value())
on_complete(*node_id);
else
on_complete(Error::from_string_literal("Unable to find DOM node to edit"));
};
edit(*view);
}
LibDevTools+LibWebView+WebContent: Implement getting DOM node inner HTML This is used by DevTools to copy the inner HTML to the clipboard.
2025-03-10 18:15:31 -04:00
void Application::get_dom_node_inner_html(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, OnDOMNodeHTMLReceived on_complete) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value()) {
on_complete(Error::from_string_literal("Unable to locate tab"));
return;
}
view->on_received_dom_node_html = [&view = *view, on_complete = move(on_complete)](auto html) {
view.on_received_dom_node_html = nullptr;
on_complete(html);
};
view->get_dom_node_inner_html(node_id);
}
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
void Application::get_dom_node_outer_html(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, OnDOMNodeHTMLReceived on_complete) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value()) {
on_complete(Error::from_string_literal("Unable to locate tab"));
return;
}
view->on_received_dom_node_html = [&view = *view, on_complete = move(on_complete)](auto html) {
view.on_received_dom_node_html = nullptr;
on_complete(html);
};
view->get_dom_node_outer_html(node_id);
}
void Application::set_dom_node_outer_html(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, String const& value, OnDOMNodeEditComplete on_complete) const
{
edit_dom_node(description, move(on_complete), [&](auto& view) {
view.set_dom_node_outer_html(node_id, value);
});
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void Application::set_dom_node_text(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, String const& value, OnDOMNodeEditComplete on_complete) const
LibDevTools+LibWebView: Implement requests to edit DOM node text
2025-03-06 19:56:40 -05:00
{
edit_dom_node(description, move(on_complete), [&](auto& view) {
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
view.set_dom_node_text(node_id, value);
LibDevTools+LibWebView: Implement requests to edit DOM node text
2025-03-06 19:56:40 -05:00
});
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void Application::set_dom_node_tag(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, String const& value, OnDOMNodeEditComplete on_complete) const
LibDevTools+LibWebView: Implement requests to edit DOM node tags
2025-03-07 09:26:36 -05:00
{
edit_dom_node(description, move(on_complete), [&](auto& view) {
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
view.set_dom_node_tag(node_id, value);
LibDevTools+LibWebView: Implement requests to edit DOM node tags
2025-03-07 09:26:36 -05:00
});
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void Application::add_dom_node_attributes(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, ReadonlySpan<Attribute> replacement_attributes, OnDOMNodeEditComplete on_complete) const
LibDevTools+LibWebView: Implement requests to edit DOM node attributes
2025-03-05 16:58:38 -05:00
{
edit_dom_node(description, move(on_complete), [&](auto& view) {
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
view.add_dom_node_attributes(node_id, replacement_attributes);
LibDevTools+LibWebView: Implement requests to edit DOM node attributes
2025-03-05 16:58:38 -05:00
});
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void Application::replace_dom_node_attribute(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, String const& name, ReadonlySpan<Attribute> replacement_attributes, OnDOMNodeEditComplete on_complete) const
LibDevTools+LibWebView: Implement requests to edit DOM node attributes
2025-03-05 16:58:38 -05:00
{
edit_dom_node(description, move(on_complete), [&](auto& view) {
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
view.replace_dom_node_attribute(node_id, name, replacement_attributes);
LibDevTools+LibWebView: Implement requests to edit DOM node attributes
2025-03-05 16:58:38 -05:00
});
}
LibDevTools+LibWebView: Implement requests to create DOM nodes This requires a couple of amendments to the DOM node serialization. Namely, we need to include the HTML namespace, otherwise the context menu item to create a new node is disabled.
2025-03-07 09:19:28 -05:00
void Application::create_child_element(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, OnDOMNodeEditComplete on_complete) const
{
edit_dom_node(description, move(on_complete), [&](auto& view) {
view.create_child_element(node_id);
});
}
LibDevTools+LibWebView+WebContent: Implement moving DOM nodes This allows for click-and-dragging DOM nodes in DevTools to move them.
2025-03-10 18:01:29 -04:00
void Application::insert_dom_node_before(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, Web::UniqueNodeID parent_node_id, Optional<Web::UniqueNodeID> sibling_node_id, OnDOMNodeEditComplete on_complete) const
{
edit_dom_node(description, move(on_complete), [&](auto& view) {
view.insert_dom_node_before(node_id, parent_node_id, sibling_node_id);
});
}
LibDevTools+LibWebView: Implement requests to clone DOM nodes
2025-03-07 09:44:24 -05:00
void Application::clone_dom_node(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, OnDOMNodeEditComplete on_complete) const
{
edit_dom_node(description, move(on_complete), [&](auto& view) {
view.clone_dom_node(node_id);
});
}
LibDevTools+LibWebView: Implement requests to delete DOM nodes
2025-03-06 20:08:27 -05:00
void Application::remove_dom_node(DevTools::TabDescription const& description, Web::UniqueNodeID node_id, OnDOMNodeEditComplete on_complete) const
{
edit_dom_node(description, move(on_complete), [&](auto& view) {
view.remove_dom_node(node_id);
});
}
LibDevTools+LibWebView: Implement getting document style sheets
2025-03-11 17:14:54 -04:00
void Application::retrieve_style_sheets(DevTools::TabDescription const& description, OnStyleSheetsReceived on_complete) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value()) {
on_complete(Error::from_string_literal("Unable to locate tab"));
return;
}
view->on_received_style_sheet_list = [&view = *view, on_complete = move(on_complete)](Vector<Web::CSS::StyleSheetIdentifier> style_sheets) {
view.on_received_style_sheet_list = nullptr;
on_complete(move(style_sheets));
};
view->list_style_sheets();
}
void Application::retrieve_style_sheet_source(DevTools::TabDescription const& description, Web::CSS::StyleSheetIdentifier const& style_sheet) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
view->request_style_sheet_source(style_sheet);
}
void Application::listen_for_style_sheet_sources(DevTools::TabDescription const& description, OnStyleSheetSourceReceived on_style_sheet_source_received) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
view->on_received_style_sheet_source = [&view = *view, on_style_sheet_source_received = move(on_style_sheet_source_received)](auto const& style_sheet, auto const&, auto const& source) {
on_style_sheet_source_received(style_sheet, source);
};
}
void Application::stop_listening_for_style_sheet_sources(DevTools::TabDescription const& description) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
view->on_received_style_sheet_source = nullptr;
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void Application::evaluate_javascript(DevTools::TabDescription const& description, String const& script, OnScriptEvaluationComplete on_complete) const
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
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value()) {
on_complete(Error::from_string_literal("Unable to locate tab"));
return;
}
view->on_received_js_console_result = [&view = *view, on_complete = move(on_complete)](JsonValue result) {
view.on_received_js_console_result = nullptr;
on_complete(move(result));
};
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
view->js_console_input(script);
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
}
LibWebView+WebContent: Implement basic DevTools console support
2025-03-04 08:48:20 -05:00
void Application::listen_for_console_messages(DevTools::TabDescription const& description, OnConsoleMessageAvailable on_console_message_available, OnReceivedConsoleMessages on_received_console_output) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
view->on_console_message_available = move(on_console_message_available);
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
view->on_received_console_messages = move(on_received_console_output);
LibWebView+WebContent: Implement basic DevTools console support
2025-03-04 08:48:20 -05:00
view->js_console_request_messages(0);
}
void Application::stop_listening_for_console_messages(DevTools::TabDescription const& description) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
view->on_console_message_available = nullptr;
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
view->on_received_console_messages = nullptr;
LibWebView+WebContent: Implement basic DevTools console support
2025-03-04 08:48:20 -05:00
}
void Application::request_console_messages(DevTools::TabDescription const& description, i32 start_index) const
{
auto view = ViewImplementation::find_view_by_id(description.id);
if (!view.has_value())
return;
view->js_console_request_messages(start_index);
}
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
}
Reference in a new issue Copy permalink