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.h

249 lines
13 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
*/
#pragma once
LibWebView: Add facilities to ask the user for a download directory If the Downloads directory exists, we will use it (note that this will respect the XDG_DOWNLOAD_DIR environment variable). Otherwise, we will ask the UI layer to retrieve a download directory from the user. This directory is not saved, so it will be re-prompted every time. Once a proper settings UI is complete, we will of course integrate with that for persistent settings.
2024-08-28 15:29:51 -04:00
#include <AK/ByteString.h>
#include <AK/LexicalPath.h>
#include <AK/Optional.h>
AK+LibGfx+LibWebView: Add wrapper header around swift/bridging When using a configuration without a swift compiler, we need to no-op the swift annotations. Other, cleverer solutions beyond the has include all fell flat in the face of the clang modules implementation used by swift to parse-once use-everywhere each module.
2024-08-17 20:13:54 -06:00
#include <AK/Swift.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 <LibCore/EventLoop.h>
LibWebView+WebContent: Monitor for system time zone changes This creates a TimeZoneWatcher in the UI process to inform all open WebContent processes when the time zone changes. The WebContent process will clear its time zone cache to retrieve a fresh zone the next time it is asked for one.
2024-08-24 12:15:20 -04:00
#include <LibCore/Forward.h>
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
#include <LibDevTools/DevToolsDelegate.h>
#include <LibDevTools/Forward.h>
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
#include <LibImageDecoderClient/Client.h>
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
#include <LibMain/Main.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 <LibRequests/RequestClient.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 <LibURL/URL.h>
LibWebView+UI: Generate the preferred color, contrast, and motion menus
2025-09-03 11:23:09 -04:00
#include <LibWeb/CSS/PreferredColorScheme.h>
#include <LibWeb/CSS/PreferredContrast.h>
#include <LibWeb/CSS/PreferredMotion.h>
LibWebView+UI: Move clipboard handling from the WebView to the App Clipboard handling largely has nothing to do with the individual web views. Rather, we interact with the system clipboard at the application level. So let's move these implementations to the Application.
2025-09-18 08:16:36 -04:00
#include <LibWeb/Clipboard/SystemClipboard.h>
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 09:08:24 -04:00
#include <LibWeb/HTML/ActivateTab.h>
LibWebView: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-01 20:55:11 -07:00
#include <LibWebView/Forward.h>
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
#include <LibWebView/Options.h>
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
#include <LibWebView/Process.h>
#include <LibWebView/ProcessManager.h>
LibWebView+UI: Introduce a persistent settings object This adds a WebView::Settings class to own persistent browser settings. In this first pass, it now owns the new tab page URL and search engine settings. For simplicitly, we currently use a JSON format for these settings. They are stored alongside the cookie database. As of this commit, the saved JSON will have the form: { "newTabPageURL": "about:blank", "searchEngine": { "name": "Google" } } (The search engine is an object to allow room for a future patch to implement custom search engine URLs.) For Qt, this replaces the management of these particular settings in the Qt settings UI. We will have an internal browser page to control these settings instead. In the future, we will want to port all settings to this new class. We will also want to allow UI-specific settings (such as whether the hamburger menu is displayed in Qt).
2025-03-20 12:59:44 -04:00
#include <LibWebView/Settings.h>
Everywhere: Implement persistence of localStorage using sqlite This change follows the pattern of our cookies persistence implementation: the "browser" process is responsible for interacting with the sqlite database, and WebContent communicates all storage operations via IPC. The new database table uses (storage_endpoint, storage_key, bottle_key) as the primary key. This design follows concepts from the https://storage.spec.whatwg.org/ and is intended to support reuse of the persistence layer for other APIs (e.g., CacheStorage, IndexedDB). For now, `storage_endpoint` is always "localStorage", `storage_key` is the website's origin, and `bottle_key` is the name of the localStorage key.
2025-06-08 23:35:46 +02:00
#include <LibWebView/StorageJar.h>
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
namespace WebView {
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 12:37:05 -04:00
struct ApplicationSettingsObserver;
LibWebView: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-01 20:55:11 -07:00
class WEBVIEW_API Application : public DevTools::DevToolsDelegate {
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
AK_MAKE_NONCOPYABLE(Application);
public:
virtual ~Application();
LibWebView+WebDriver+UI: Migrate headless browsing to main Ladybird exe We currently create a separate headless-browser application to serve two purposes: 1. Allow headless browsing to take a screenshot of a page or print its layout tree / internal text. 2. Run the LibWeb test framework. This patch migrates (1) to the main Ladybird executable. The --headless flag enables this mode. This matches the behavior of other browsers, and means we have one less executable to ship at distribution time. We want to avoid creating too many AppKit / Qt facilities in headless mode. So this involves some shuffling of application init to ensure we don't create them until after we've parsed the command line arguments. Namely, we avoid creating the NSApp in AppKit and QCoreApplication in Qt. Doing so also requires that we don't create the application event loop until we've parsed the command line as well, because the loop we create depends on whether we're creating those UI facilities.
2025-06-06 15:42:12 -04:00
ErrorOr<int> execute();
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
static Application& the() { return *s_the; }
LibWebView+UI: Introduce a persistent settings object This adds a WebView::Settings class to own persistent browser settings. In this first pass, it now owns the new tab page URL and search engine settings. For simplicitly, we currently use a JSON format for these settings. They are stored alongside the cookie database. As of this commit, the saved JSON will have the form: { "newTabPageURL": "about:blank", "searchEngine": { "name": "Google" } } (The search engine is an object to allow room for a future patch to implement custom search engine URLs.) For Qt, this replaces the management of these particular settings in the Qt settings UI. We will have an internal browser page to control these settings instead. In the future, we will want to port all settings to this new class. We will also want to allow UI-specific settings (such as whether the hamburger menu is displayed in Qt).
2025-03-20 12:59:44 -04:00
static Settings& settings() { return the().m_settings; }
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 16:56:52 -04:00
static BrowserOptions const& browser_options() { return the().m_browser_options; }
LibWebView+UI: Read and set echo server port in `HttpEchoServerFixture` This commit adds a "echo_server_port" property to `WebContentOptions`. Additionally, it makes `Application::web_content_options()` return a mutable reference instead of a const reference so that we can set the port value from the fixture.
2024-12-02 19:33:26 -06:00
static WebContentOptions& web_content_options() { return the().m_web_content_options; }
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -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
static Requests::RequestClient& request_server_client() { return *the().m_request_server_client; }
static ImageDecoderClient::Client& image_decoder_client() { return *the().m_image_decoder_client; }
LibWebView+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
static CookieJar& cookie_jar() { return *the().m_cookie_jar; }
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
static StorageJar& storage_jar() { return *the().m_storage_jar; }
LibWebView+UI: Move the database and cookie jar to WebView::Application The main motivator here was noticing that --disable-sql-database did not work with AppKit. Rather than re-implementing this there, move ownership of these classes to WebView::Application, so that each UI does not need to individually worry about it.
2024-09-05 18:19:51 -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
static ProcessManager& process_manager() { return *the().m_process_manager; }
LibWeb+LibWebView+WebContent: Convert about:processes to a WebUI
2025-03-24 09:50:12 -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
ErrorOr<NonnullRefPtr<WebContentClient>> launch_web_content_process(ViewImplementation&);
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
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
virtual Optional<ViewImplementation&> active_web_view() const { return {}; }
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 09:08:24 -04:00
virtual Optional<ViewImplementation&> open_blank_new_tab(Web::HTML::ActivateTab) const { return {}; }
void open_url_in_new_tab(URL::URL const&, Web::HTML::ActivateTab) const;
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
void add_child_process(Process&&);
// FIXME: Should these methods be part of Application, instead of deferring to ProcessManager?
#if defined(AK_OS_MACH)
void set_process_mach_port(pid_t, Core::MachPort&&);
#endif
Optional<Process&> find_process(pid_t);
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> path_for_downloaded_file(StringView file) const;
LibWebView+UI: Extract some UI-specific displays to Application helpers This is preparation for moving application menus to LibWebView. We will need a way to display these dialogs from outside of the UI layer.
2025-09-04 08:53:57 -04:00
virtual void display_download_confirmation_dialog(StringView download_name, LexicalPath const& path) const;
virtual void display_error_dialog(StringView error_message) const;
LibWeb+WebContent+UI: Port text pasting to UTF-16
2025-09-18 09:18:54 -04:00
virtual Utf16String clipboard_text() const { return {}; }
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
virtual Vector<Web::Clipboard::SystemClipboardRepresentation> clipboard_entries() const { return {}; }
virtual void insert_clipboard_entry(Web::Clipboard::SystemClipboardRepresentation) { }
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
Action& reload_action() { return *m_reload_action; }
Action& copy_selection_action() { return *m_copy_selection_action; }
Action& paste_action() { return *m_paste_action; }
Action& select_all_action() { return *m_select_all_action; }
LibWebView+UI: Generate actions to open about: pages
2025-09-17 09:18:08 -04:00
Action& open_about_page_action() { return *m_open_about_page_action; }
Action& open_settings_page_action() { return *m_open_settings_page_action; }
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
LibWebView+UI: Generate the zoom menu
2025-09-10 07:23:15 -04:00
Menu& zoom_menu() { return *m_zoom_menu; }
Action& reset_zoom_action() { return *m_reset_zoom_action; }
LibWebView+UI: Generate the preferred color, contrast, and motion menus
2025-09-03 11:23:09 -04:00
Menu& color_scheme_menu() { return *m_color_scheme_menu; }
Menu& contrast_menu() { return *m_contrast_menu; }
Menu& motion_menu() { return *m_motion_menu; }
LibWebView+UI: Generate the entire Inspect menu Now that all the actions in the Inspect menu are generated, we can generate the menu itself.
2025-09-17 10:22:23 -04:00
Menu& inspect_menu() { return *m_inspect_menu; }
Action& view_source_action() { return *m_view_source_action; }
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 09:00:52 -04:00
Menu& debug_menu() { return *m_debug_menu; }
void apply_view_options(Badge<ViewImplementation>, ViewImplementation&);
LibWebView+UI: Generate action to enable/disable DevTools
2025-09-17 10:03:01 -04:00
ErrorOr<void> toggle_devtools_enabled();
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
void refresh_tab_list();
LibCore+LibWebView+UI/Qt: Support TimeZoneWatcher on Windows To detect system time zone changes on Windows, the event we need to look for is WM_TIMECHANGE. The problem is how the callback with said message actually gets invoked is very particular. (1) We must have an active message pump (event loop) for the message to ever be processed. (2) We must be a GUI application as WM_TIMECHANGE messages are seemingly sent to top level windows only. It doesn't say that in the docs for the event, but attempts of creating a LibTest-based application with a message pump and a message only window and never receiving the event point to that probably being true. This workaround is built off the fact that Qt's message pump defined internally in QEventDispatcherWin32::processEvents does in fact receive WM_TIMECHANGE events, even though it is not exposed as a QEvent::Type. Given the requirements stated above it makes sense that it works here as the message pump is executing in a QGuiApplication context. So we use a native event filter to hook into the unexposed WM_TIMECHANGE event and forward it along to the on_time_zone_changed() callback. Note that if a Windows GUI framework is done in the future, we'll have to re-add support to ensure the TimeZoneWatcher still gets invoked.
2025-09-16 18:06:00 -07:00
Optional<Core::TimeZoneWatcher&> time_zone_watcher();
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
protected:
LibWebView+UI: Migrate some UI process init to LibWebView No need to do this setup in every UI's main().
2025-06-10 19:20:46 -04:00
explicit Application(Optional<ByteString> ladybird_binary_path = {});
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 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
ErrorOr<void> initialize(Main::Arguments const&);
LibWebView+UI: Don't declare a magic ctor for Application subclasses You would have to just know that you need to define the constructor with this declaration. Let's allow subclasses to define constructors as they see fit.
2025-06-10 19:13:03 -04:00
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
virtual void process_did_exit(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
virtual void create_platform_arguments(Core::ArgsParser&) { }
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 16:56:52 -04:00
virtual void create_platform_options(BrowserOptions&, WebContentOptions&) { }
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
virtual NonnullOwnPtr<Core::EventLoop> create_platform_event_loop();
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
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
virtual Optional<ByteString> ask_user_for_download_folder() const { return {}; }
LibWebView+UI: Generate action to enable/disable DevTools
2025-09-17 10:03:01 -04:00
virtual void on_devtools_enabled() const;
virtual void on_devtools_disabled() const;
LibWebView+UI: Do not create a QApplication in headless mode This is causing errors on the WPT runner, which does not have a display output. To do this requires shuffling around the Main::Arguments struct, as we now need access to it from overridden WebView::Application methods after construction.
2025-06-10 14:56:24 -04:00
Main::Arguments& arguments() { return m_arguments; }
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
private:
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> launch_services();
LibWebView: Create a spare WebContent process Since cross-site navigation is a pretty frequent task, creating a spare process is commonplace in other browsers to reduce the overhead of directing the target site to a new process. We store this process on the WebView application. If it is unavailable, we queue a task to create it later.
2025-03-09 18:01:25 -04:00
void launch_spare_web_content_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
ErrorOr<void> launch_request_server();
ErrorOr<void> launch_image_decoder_server();
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
ErrorOr<void> launch_devtools_server();
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 initialize_actions();
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
virtual Vector<DevTools::TabDescription> tab_list() const override;
virtual Vector<DevTools::CSSProperty> css_property_list() const override;
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 16:22:12 -05:00
virtual void inspect_tab(DevTools::TabDescription const&, OnTabInspectionComplete) const override;
LibDevTools+LibWebView+WebContent: Selectively fetch DOM node properties When we inspect a DOM node, we currently serialize many properties for that node, including its layout, computed style, used fonts, etc. Now that we aren't piggy-backing on the Inspector interface, we can instead only serialize the specific information required by DevTools.
2025-03-19 15:50:56 -04:00
virtual void listen_for_dom_properties(DevTools::TabDescription const&, OnDOMNodePropertiesReceived) const override;
virtual void stop_listening_for_dom_properties(DevTools::TabDescription const&) const override;
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
virtual void inspect_dom_node(DevTools::TabDescription const&, DOMNodeProperties::Type, Web::UniqueNodeID, Optional<Web::CSS::PseudoElement>) const override;
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 16:22:12 -05:00
virtual void clear_inspected_dom_node(DevTools::TabDescription const&) const override;
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
virtual void highlight_dom_node(DevTools::TabDescription const&, Web::UniqueNodeID, Optional<Web::CSS::PseudoElement>) const override;
LibWebView: Support DOM node highlighting and inspection for DevTools
2025-02-21 16:22:12 -05:00
virtual void clear_highlighted_dom_node(DevTools::TabDescription const&) const override;
LibDevTools+LibWebView: Inform the DevTools client about DOM mutations
2025-03-06 19:56:03 -05:00
virtual void listen_for_dom_mutations(DevTools::TabDescription const&, OnDOMMutationReceived) const override;
virtual void stop_listening_for_dom_mutations(DevTools::TabDescription const&) const override;
LibDevTools+LibWebView+WebContent: Implement getting DOM node inner HTML This is used by DevTools to copy the inner HTML to the clipboard.
2025-03-10 18:15:31 -04:00
virtual void get_dom_node_inner_html(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeHTMLReceived) const override;
LibDevTools+LibWebView+WebContent: Implement editing DOM node HTML These commands are used for the "Edit As HTML" feature in DevTools. This renames our existing HTML getter IPC to indicate that it is for outer HTML. DevTools will need a separate inner HTML getter.
2025-03-10 17:36:41 -04:00
virtual void get_dom_node_outer_html(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeHTMLReceived) const override;
virtual void set_dom_node_outer_html(DevTools::TabDescription const&, Web::UniqueNodeID, String const&, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
virtual void set_dom_node_text(DevTools::TabDescription const&, Web::UniqueNodeID, String const&, OnDOMNodeEditComplete) const override;
virtual void set_dom_node_tag(DevTools::TabDescription const&, Web::UniqueNodeID, String const&, OnDOMNodeEditComplete) const override;
virtual void add_dom_node_attributes(DevTools::TabDescription const&, Web::UniqueNodeID, ReadonlySpan<Attribute>, OnDOMNodeEditComplete) const override;
virtual void replace_dom_node_attribute(DevTools::TabDescription const&, Web::UniqueNodeID, String const&, ReadonlySpan<Attribute>, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Implement requests to create DOM nodes This requires a couple of amendments to the DOM node serialization. Namely, we need to include the HTML namespace, otherwise the context menu item to create a new node is disabled.
2025-03-07 09:19:28 -05:00
virtual void create_child_element(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView+WebContent: Implement moving DOM nodes This allows for click-and-dragging DOM nodes in DevTools to move them.
2025-03-10 18:01:29 -04:00
virtual void insert_dom_node_before(DevTools::TabDescription const&, Web::UniqueNodeID, Web::UniqueNodeID, Optional<Web::UniqueNodeID>, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Implement requests to clone DOM nodes
2025-03-07 09:44:24 -05:00
virtual void clone_dom_node(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Implement requests to delete DOM nodes
2025-03-06 20:08:27 -05:00
virtual void remove_dom_node(DevTools::TabDescription const&, Web::UniqueNodeID, OnDOMNodeEditComplete) const override;
LibDevTools+LibWebView: Implement getting document style sheets
2025-03-11 17:14:54 -04:00
virtual void retrieve_style_sheets(DevTools::TabDescription const&, OnStyleSheetsReceived) const override;
virtual void retrieve_style_sheet_source(DevTools::TabDescription const&, Web::CSS::StyleSheetIdentifier const&) const override;
virtual void listen_for_style_sheet_sources(DevTools::TabDescription const&, OnStyleSheetSourceReceived) const override;
virtual void stop_listening_for_style_sheet_sources(DevTools::TabDescription const&) const override;
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
virtual void evaluate_javascript(DevTools::TabDescription const&, String const&, OnScriptEvaluationComplete) const override;
LibWebView+WebContent: Implement basic DevTools console support
2025-03-04 08:48:20 -05:00
virtual void listen_for_console_messages(DevTools::TabDescription const&, OnConsoleMessageAvailable, OnReceivedConsoleMessages) const override;
virtual void stop_listening_for_console_messages(DevTools::TabDescription const&) const override;
virtual void request_console_messages(DevTools::TabDescription const&, i32) const override;
LibWebView+UI: Move ownership of application services to LibWebView LibWebView now knows how to launch RequestServer and ImageDecoderServer without help from the UI, so let's move ownership of these services over to LibWebView for de-duplication.
2024-11-13 15:33:02 -05:00
LibWebView+LibCore: Manage process lifecycle using a SIGCHLD handler This large commit also refactors LibWebView's process handling to use a top-level Application class that uses a new WebView::Process class to encapsulate the IPC-centric nature of each helper process.
2024-06-29 22:24:01 -06:00
static Application* s_the;
LibWebView+UI: Introduce a persistent settings object This adds a WebView::Settings class to own persistent browser settings. In this first pass, it now owns the new tab page URL and search engine settings. For simplicitly, we currently use a JSON format for these settings. They are stored alongside the cookie database. As of this commit, the saved JSON will have the form: { "newTabPageURL": "about:blank", "searchEngine": { "name": "Google" } } (The search engine is an object to allow room for a future patch to implement custom search engine URLs.) For Qt, this replaces the management of these particular settings in the Qt settings UI. We will have an internal browser page to control these settings instead. In the future, we will want to port all settings to this new class. We will also want to allow UI-specific settings (such as whether the hamburger menu is displayed in Qt).
2025-03-20 12:59:44 -04:00
Settings m_settings;
LibWebView: Create a dedicated settings observer for the Application We had a bit of an awkward setup where we want the Application to be a SettingsObserver, but neither the Settings object nor the Application itself was fully initialized by the time the observer was created. So we invented a deferred observer initializer specifically for the Application. Instead, let's just create a dedicated observer subclass that is owned by the Application. We can then create it once we have the singleton Application appropriately set up.
2025-04-23 12:37:05 -04:00
OwnPtr<ApplicationSettingsObserver> m_settings_observer;
LibWebView+UI: Introduce a persistent settings object This adds a WebView::Settings class to own persistent browser settings. In this first pass, it now owns the new tab page URL and search engine settings. For simplicitly, we currently use a JSON format for these settings. They are stored alongside the cookie database. As of this commit, the saved JSON will have the form: { "newTabPageURL": "about:blank", "searchEngine": { "name": "Google" } } (The search engine is an object to allow room for a future patch to implement custom search engine URLs.) For Qt, this replaces the management of these particular settings in the Qt settings UI. We will have an internal browser page to control these settings instead. In the future, we will want to port all settings to this new class. We will also want to allow UI-specific settings (such as whether the hamburger menu is displayed in Qt).
2025-03-20 12:59:44 -04:00
LibWebView+UI: Do not create a QApplication in headless mode This is causing errors on the WPT runner, which does not have a display output. To do this requires shuffling around the Main::Arguments struct, as we now need access to it from overridden WebView::Application methods after construction.
2025-06-10 14:56:24 -04:00
Main::Arguments m_arguments;
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 16:56:52 -04:00
BrowserOptions m_browser_options;
LibWebView+UI: Migrate Ladybird's command line flags to LibWebView Currently, if we want to add a new e.g. WebContent command line option, we have to add it to all of Qt, AppKit, and headless-browser. (Or worse, we only add it to one of these, and we have feature disparity). To prevent this, this moves command line flags to WebView::Application. The flags are assigned to ChromeOptions and WebContentOptions structs. Each chrome can still add its platform-specific options; for example, the Qt chrome has a flag to enable Qt networking. There should be no behavior change here, other than that AppKit will now support command line flags that were previously only supported by Qt.
2024-07-30 14:01:05 -04:00
WebContentOptions m_web_content_options;
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
RefPtr<Requests::RequestClient> m_request_server_client;
RefPtr<ImageDecoderClient::Client> m_image_decoder_client;
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
RefPtr<WebContentClient> m_spare_web_content_process;
bool m_has_queued_task_to_launch_spare_web_content_process { false };
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
RefPtr<Database> m_database;
OwnPtr<CookieJar> m_cookie_jar;
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
OwnPtr<StorageJar> m_storage_jar;
LibWebView+UI: Move the database and cookie jar to WebView::Application The main motivator here was noticing that --disable-sql-database did not work with AppKit. Rather than re-implementing this there, move ownership of these classes to WebView::Application, so that each UI does not need to individually worry about it.
2024-09-05 18:19:51 -04:00
LibWebView+WebContent: Monitor for system time zone changes This creates a TimeZoneWatcher in the UI process to inform all open WebContent processes when the time zone changes. The WebContent process will clear its time zone cache to retrieve a fresh zone the next time it is asked for one.
2024-08-24 12:15:20 -04:00
OwnPtr<Core::TimeZoneWatcher> m_time_zone_watcher;
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<Core::EventLoop> m_event_loop;
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
OwnPtr<ProcessManager> m_process_manager;
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
RefPtr<Action> m_reload_action;
RefPtr<Action> m_copy_selection_action;
RefPtr<Action> m_paste_action;
RefPtr<Action> m_select_all_action;
LibWebView+UI: Generate actions to open about: pages
2025-09-17 09:18:08 -04:00
RefPtr<Action> m_open_about_page_action;
RefPtr<Action> m_open_settings_page_action;
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
LibWebView+UI: Generate the zoom menu
2025-09-10 07:23:15 -04:00
RefPtr<Menu> m_zoom_menu;
RefPtr<Action> m_reset_zoom_action;
LibWebView+UI: Generate the preferred color, contrast, and motion menus
2025-09-03 11:23:09 -04:00
RefPtr<Menu> m_color_scheme_menu;
Web::CSS::PreferredColorScheme m_color_scheme { Web::CSS::PreferredColorScheme::Auto };
RefPtr<Menu> m_contrast_menu;
Web::CSS::PreferredContrast m_contrast { Web::CSS::PreferredContrast::Auto };
RefPtr<Menu> m_motion_menu;
Web::CSS::PreferredMotion m_motion { Web::CSS::PreferredMotion::Auto };
LibWebView+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
RefPtr<Menu> m_inspect_menu;
RefPtr<Action> m_view_source_action;
RefPtr<Action> m_toggle_devtools_action;
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 09:00:52 -04:00
RefPtr<Menu> m_debug_menu;
RefPtr<Action> m_show_line_box_borders_action;
RefPtr<Action> m_enable_scripting_action;
RefPtr<Action> m_enable_content_filtering_action;
RefPtr<Action> m_block_pop_ups_action;
StringView m_user_agent_string;
StringView m_navigator_compatibility_mode;
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)
OwnPtr<MachPortServer> m_mach_port_server;
#endif
LibWebView: Integrate the DevTools server into the WebView application This adds a command line option to enable the DevTools server. Here, we make the application the DevToolsDelegate to reply to requests from the DevTools server about the state of the application.
2025-02-15 08:09:47 -05:00
OwnPtr<DevTools::DevToolsServer> m_devtools;
Ladybird/AppKit: Port TaskManager window to Swift This is just a direct port of the Objective-C++ code to Swift 6. A future patch should probably update it to actually use SwiftUI.
2024-07-16 05:33:39 -06:00
} SWIFT_IMMORTAL_REFERENCE;
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+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+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
#define WEB_VIEW_APPLICATION(ApplicationType) \
public: \
template<typename... ApplicationArguments> \
static ErrorOr<NonnullOwnPtr<ApplicationType>> create(Main::Arguments const& arguments, ApplicationArguments&&... application_arguments) \
{ \
auto app = adopt_own(*new ApplicationType { forward<ApplicationArguments>(application_arguments)... }); \
TRY(app->initialize(arguments)); \
return app; \
} \
\
static ApplicationType& the() \
{ \
return static_cast<ApplicationType&>(WebView::Application::the()); \
} \
\
LibWebView: Make WEB_VIEW_APPLICATION switch back to a private section Let's not leave everything after the WEB_VIEW_APPLICATION invocation public.
2025-06-10 19:15:40 -04:00
private:
Reference in a new issue Copy permalink