Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-03 23:00:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Services/WebContent/ConnectionFromClient.h

174 lines
8.5 KiB
C
Raw Normal View History

WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
/*
Meta: Update my e-mail address everywhere
2024-10-04 13:19:50 +02:00
* Copyright (c) 2018-2023, Andreas Kling <andreas@ladybird.org>
WebContent: Add IPC for setting 'device pixels per CSS pixel'
2023-01-12 14:35:35 +00:00
* Copyright (c) 2021-2023, Linus Groh <linusg@serenityos.org>
LibWebView+WebConent: Add an IPC to get an element's enabled state
2022-11-03 13:30:11 -04:00
* Copyright (c) 2022, Tim Flynn <trflynn89@serenityos.org>
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
*
Everything: Move to SPDX license identifiers in all files. SPDX License Identifiers are a more compact / standardized way of representing file license information. See: https://spdx.dev/resources/use/#identifiers This was done with the `ambr` search and replace tool. ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
2021-04-22 01:24:48 -07:00
* SPDX-License-Identifier: BSD-2-Clause
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
*/
#pragma once
#include <AK/HashMap.h>
WebContent: Give paint requests a chance to happen between input events Before this patch, we had an issue where the WebContent process could get backed up with tons of pending input events (especially mouse moves) and have to work through all of those before responding to a paint request from the UI process. This could lead to a situation where we went for a very long time without seeing any visual updates. The approach I've taken here is pretty simple, we basically make a queue of all incoming input events on the WebContent process side, and then process that queue one event at a time, using a zero timer. This is basic, but it allows paint requests to come in between the input events and we do now get more frequent visual updates even during heavy pressure from input events.
2023-03-14 13:26:06 +01:00
#include <AK/Queue.h>
WebContent: Reduce IPC boilerplate within the web content process Use the existing helper function to find the page / log when the page cannot be found.
2024-03-29 10:05:05 -04:00
#include <AK/SourceLocation.h>
Userland: Rename IPC ClientConnection => ConnectionFromClient This was done with CLion's automatic rename feature and with: find . -name ClientConnection.h | rename 's/ClientConnection\.h/ConnectionFromClient.h/' find . -name ClientConnection.cpp | rename 's/ClientConnection\.cpp/ConnectionFromClient.cpp/'
2022-02-25 12:18:30 +02:00
#include <LibIPC/ConnectionFromClient.h>
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
#include <LibJS/Forward.h>
WebContent: Implement ConsoleGlobalObject which proxies to WindowObject ConsoleGlobalObject is used as the global object when running javascript from the Browser console. This lets us implement console-only functions and variables (like `$0`) without exposing them to webpage content. It passes other calls over to the usual WindowObject so any code that would have worked in the webpage will still work in the console. :^)
2021-09-03 10:16:36 +01:00
#include <LibJS/Heap/Handle.h>
LibWeb+WebContent: Add set_preferred_color_scheme IPC call This allows the owner of a WebView to override whether to use a dark theme or not, instead of just using the system theme's IsDark property.
2021-10-26 17:00:10 +01:00
#include <LibWeb/CSS/PreferredColorScheme.h>
LibWeb: Add Contrast preference
2024-06-13 01:03:56 +02:00
#include <LibWeb/CSS/PreferredContrast.h>
LibWeb: Add motion preference This adds a motion preference to the browser UI similar to the existing ones for color scheme and contrast. Both AppKit UI and Qt UI has this new preference. The auto value is currently the same as NoPreference, follow-ups can address wiring that up to the actual preference for the OS.
2024-06-13 16:15:59 +02:00
#include <LibWeb/CSS/PreferredMotion.h>
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
#include <LibWeb/Forward.h>
Browser+LibWeb+WebContent: Allow Browser to load local files To achieve this goal: - The Browser unveils "/tmp/portal/filesystemaccess" - Pass the page through LoadRequest => ResourceLoader - ResourceLoader requests a file to the FileSystemAccessServer via IPC - OutOfProcessWebView handles it and sends a file descriptor back to the Page.
2022-02-26 17:50:31 +01:00
#include <LibWeb/Loader/FileRequest.h>
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
#include <LibWeb/Page/EventResult.h>
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
#include <LibWeb/Page/InputEvent.h>
WebContent: Use Web::Platform::Timer instead of Core::Timer This will allow WebContent to operate without a Core::EventLoop.
2022-10-05 19:33:30 +02:00
#include <LibWeb/Platform/Timer.h>
LibWebView+WebContent: Add APIs to manipulate DOM nodes This adds APIs to allow Ispector clients to: * Change a DOM text or comment node's text data. * Add, replace, or remove a DOM element's attribute. * Change a DOM element's tag.
2023-11-19 10:42:11 -05:00
#include <LibWebView/Forward.h>
LibWebView+WebContent+headless-browser: Make the page info IPCs async The IPCs to request a page's text, layout tree, etc. are currently all synchronous. This can result in a deadlock when WebContent also makes a synchronous IPC call, as both ends will be waiting on each other. This replaces the page info IPCs with a single, asynchronous IPC. This new IPC is promise-based, much like our screenshot IPC.
2024-09-19 10:40:00 -04:00
#include <LibWebView/PageInfo.h>
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
#include <WebContent/Forward.h>
LibIPC: Share most of the code between {Client,Server}Connection This patch introduces IPC::Connection which becomes the new base class of ClientConnection and ServerConnection. Most of the functionality has been hoisted up to the base class since almost all of it is useful on both sides. This gives us the ability to send synchronous messages in both directions, which is needed for the WebContent server process. Unlike other servers, WebContent does not mind blocking on a response from its client.
2020-09-12 11:44:00 +02:00
#include <WebContent/WebContentClientEndpoint.h>
WebContent: Added IPC calls for initializing JS console and sending input
2021-02-27 21:44:49 -06:00
#include <WebContent/WebContentConsoleClient.h>
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
#include <WebContent/WebContentServerEndpoint.h>
namespace WebContent {
Userland: Rename IPC ClientConnection => ConnectionFromClient This was done with CLion's automatic rename feature and with: find . -name ClientConnection.h | rename 's/ClientConnection\.h/ConnectionFromClient.h/' find . -name ClientConnection.cpp | rename 's/ClientConnection\.cpp/ConnectionFromClient.cpp/'
2022-02-25 12:18:30 +02:00
class ConnectionFromClient final
: public IPC::ConnectionFromClient<WebContentClientEndpoint, WebContentServerEndpoint> {
C_OBJECT(ConnectionFromClient);
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
public:
Everywhere: Write dtors for types with incomplete members out-of-line These are rejected by Clang (19) trunk as a result of https://github.com/llvm/llvm-project/pull/77753.
2024-06-16 10:38:35 +02:00
~ConnectionFromClient() override;
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
virtual void die() override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
void request_file(u64 page_id, Web::FileRequest);
Browser+LibWeb+WebContent: Allow Browser to load local files To achieve this goal: - The Browser unveils "/tmp/portal/filesystemaccess" - Pass the page through LoadRequest => ResourceLoader - ResourceLoader requests a file to the FileSystemAccessServer via IPC - OutOfProcessWebView handles it and sends a file descriptor back to the Page.
2022-02-26 17:50:31 +01:00
WebContent: Add ConnectionFromClient::fd() accessor
2022-10-05 16:02:02 +02:00
Optional<int> fd() { return socket().fd(); }
WebContent: Provide access to ConnectionFromClient's PageHost This is needed to construct a WebDriverConnection from outside of PageHost itself in Ladybird.
2022-11-14 10:59:34 -05:00
PageHost& page_host() { return *m_page_host; }
PageHost const& page_host() const { return *m_page_host; }
Everywhere: Transition ImageDecoder to be single-instance, owned by UI This is the same behavior as RequestServer, with the added benefit that we know how to gracefully reconnect ImageDecoder to all WebContent processes on restart.
2024-06-26 13:44:42 -06:00
Function<void(IPC::File const&)> on_image_decoder_connection;
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
private:
LibCore: Move Stream-based sockets into the `Core` namespace
2023-02-08 23:05:44 +01:00
explicit ConnectionFromClient(NonnullOwnPtr<Core::LocalSocket>);
Services: Fix visibility of Object-derivative constructors Derivatives of Core::Object should be constructed through ClassName::construct(), to avoid handling ref-counted objects with refcount zero. Fixing the visibility means that misuses like this are more difficult.
2021-10-31 23:38:04 +01:00
WebContent: Reduce IPC boilerplate within the web content process Use the existing helper function to find the page / log when the page cannot be found.
2024-03-29 10:05:05 -04:00
Optional<PageClient&> page(u64 index, SourceLocation = SourceLocation::current());
Optional<PageClient const&> page(u64 index, SourceLocation = SourceLocation::current()) const;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
WebContent: Add shutdown_server IPC call to request process exit This ensures that removing the last view from a WebContentClient will close its associated process, assuming the WebContent process is not hung. A more drastic measure will be needed to trigger forcefully killing the process when it doesn't respond to this request.
2024-06-30 19:12:22 -06:00
virtual void close_server() override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
virtual Messages::WebContentServer::GetWindowHandleResponse get_window_handle(u64 page_id) override;
virtual void set_window_handle(u64 page_id, String const& handle) override;
virtual void connect_to_webdriver(u64 page_id, ByteString const& webdriver_ipc_path) override;
Everywhere: Transition ImageDecoder to be single-instance, owned by UI This is the same behavior as RequestServer, with the added benefit that we know how to gracefully reconnect ImageDecoder to all WebContent processes on restart.
2024-06-26 13:44:42 -06:00
virtual void connect_to_image_decoder(IPC::File const& image_decoder_socket) override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
virtual void update_system_theme(u64 page_id, Core::AnonymousBuffer const&) override;
virtual void update_screen_rects(u64 page_id, Vector<Web::DevicePixelRect> const&, u32) override;
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
virtual void load_url(u64 page_id, URL::URL const&) override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
virtual void load_html(u64 page_id, ByteString const&) override;
LibWeb+LibWebView+WebContent: Add an IPC call for Navigable::reload()
2024-04-13 18:51:27 +02:00
virtual void reload(u64 page_id) override;
LibWeb+LibWebView+WebContent: Add traverse_history_by_delta() IPC call
2024-04-13 22:33:48 +02:00
virtual void traverse_the_history_by_delta(u64 page_id, i32 delta) override;
LibWeb+WebContent: Move scrollbar painting into WebContent The main intention of this change is to have a consistent look and behavior across all scrollbars, including elements with `overflow: scroll` and `overflow: auto`, iframes, and a page. Before: - Page's scrollbar is painted by Browser (Qt/AppKit) using the corresponding UI framework style, - Both WebContent and Browser know the scroll position offset. - WebContent uses did_request_scroll_to() IPC call to send updates. - Browser uses set_viewport_rect() to send updates. After: - Page's scrollbar is painted on WebContent side using the same style as currently used for elements with `overflow: scroll` and `overflow: auto`. A nice side effects: scrollbars are now painted for iframes, and page's scrollbar respects scrollbar-width CSS property. - Only WebContent knows scroll position offset. - did_request_scroll_to() is no longer used. - set_viewport_rect() is changed to set_viewport_size().
2024-06-03 17:53:55 +03:00
virtual void set_viewport_size(u64 page_id, Web::DevicePixelSize const) override;
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
virtual void key_event(u64 page_id, Web::KeyEvent const&) override;
virtual void mouse_event(u64 page_id, Web::MouseEvent const&) override;
LibWeb+LibWebView+WebContent: Add IPC to send drag-and-drop events This adds the IPC and related hooks to allow the UI to send drag-and- drop events from the UI process to the WebContent process.
2024-08-17 13:36:28 -04:00
virtual void drag_event(u64 page_id, Web::DragEvent const&) override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
virtual void ready_to_paint(u64 page_id) override;
virtual void debug_request(u64 page_id, ByteString const&, ByteString const&) override;
virtual void get_source(u64 page_id) override;
virtual void inspect_dom_tree(u64 page_id) override;
virtual void inspect_dom_node(u64 page_id, i32 node_id, Optional<Web::CSS::Selector::PseudoElement::Type> const& pseudo_element) override;
virtual void inspect_accessibility_tree(u64 page_id) override;
virtual void get_hovered_node_id(u64 page_id) override;
Inspector: Add a basic style sheet inspector Choosing options from the `<select>` will load and display that style sheet's source text, with some checks to make sure that the text that just loaded is the one we currently want. The UI is a little goofy when scrolling, as it uses `position: sticky` which we don't implement yet. But that's just more motivation to implement it! :^)
2024-08-23 11:18:35 +01:00
virtual void list_style_sheets(u64 page_id) override;
virtual void request_style_sheet_source(u64 page_id, Web::CSS::StyleSheetIdentifier const& identifier) override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
virtual void set_dom_node_text(u64 page_id, i32 node_id, String const& text) override;
virtual void set_dom_node_tag(u64 page_id, i32 node_id, String const& name) override;
virtual void add_dom_node_attributes(u64 page_id, i32 node_id, Vector<WebView::Attribute> const& attributes) override;
virtual void replace_dom_node_attribute(u64 page_id, i32 node_id, String const& name, Vector<WebView::Attribute> const& replacement_attributes) override;
virtual void create_child_element(u64 page_id, i32 node_id) override;
virtual void create_child_text_node(u64 page_id, i32 node_id) override;
virtual void clone_dom_node(u64 page_id, i32 node_id) override;
virtual void remove_dom_node(u64 page_id, i32 node_id) override;
virtual void get_dom_node_html(u64 page_id, i32 node_id) override;
virtual void set_content_filters(u64 page_id, Vector<String> const&) override;
virtual void set_autoplay_allowed_on_all_websites(u64 page_id) override;
virtual void set_autoplay_allowlist(u64 page_id, Vector<String> const& allowlist) override;
virtual void set_proxy_mappings(u64 page_id, Vector<ByteString> const&, HashMap<ByteString, size_t> const&) override;
virtual void set_preferred_color_scheme(u64 page_id, Web::CSS::PreferredColorScheme const&) override;
LibWeb: Add Contrast preference
2024-06-13 01:03:56 +02:00
virtual void set_preferred_contrast(u64 page_id, Web::CSS::PreferredContrast const&) override;
LibWeb: Add motion preference This adds a motion preference to the browser UI similar to the existing ones for color scheme and contrast. Both AppKit UI and Qt UI has this new preference. The auto value is currently the same as NoPreference, follow-ups can address wiring that up to the actual preference for the OS.
2024-06-13 16:15:59 +02:00
virtual void set_preferred_motion(u64 page_id, Web::CSS::PreferredMotion const&) override;
LibWeb: Make preferred languages configurable This also changes fetch to use the preferred languages for the Accept-Language header.
2024-07-23 21:10:24 +01:00
virtual void set_preferred_languages(u64 page_id, Vector<String> const&) override;
LibWeb: Support sending DNT header with requests
2024-07-02 20:29:43 +01:00
virtual void set_enable_do_not_track(u64 page_id, bool) override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
virtual void set_has_focus(u64 page_id, bool) override;
virtual void set_is_scripting_enabled(u64 page_id, bool) override;
virtual void set_device_pixels_per_css_pixel(u64 page_id, float) override;
virtual void set_window_position(u64 page_id, Web::DevicePixelPoint) override;
virtual void set_window_size(u64 page_id, Web::DevicePixelSize) override;
virtual void handle_file_return(u64 page_id, i32 error, Optional<IPC::File> const& file, i32 request_id) override;
virtual void set_system_visibility_state(u64 page_id, bool visible) override;
virtual void js_console_input(u64 page_id, ByteString const&) override;
virtual void run_javascript(u64 page_id, ByteString const&) override;
virtual void js_console_request_messages(u64 page_id, i32) override;
virtual void alert_closed(u64 page_id) override;
virtual void confirm_closed(u64 page_id, bool accepted) override;
virtual void prompt_closed(u64 page_id, Optional<String> const& response) override;
virtual void color_picker_update(u64 page_id, Optional<Color> const& picked_color, Web::HTML::ColorPickerUpdateState const& state) override;
LibWeb+LibWebView+WebContent: Implement more <input type=file> behavior We had previous implemented some plumbing for file input elements in commit 636602a54e55945f7394805975a69dc40934331c. This implements the return path for chromes to inform WebContent of the file(s) the user selected. This patch includes a dummy implementation for headless-browser to enable testing.
2024-02-25 13:02:47 -05:00
virtual void file_picker_closed(u64 page_id, Vector<Web::HTML::SelectedFile> const& selected_files) override;
LibWeb: Refactor SelectItem to allow selecting options without value Currently the `<select>` dropdown IPC uses the option value attr to find which option is selected. This won't work when options don't have values or when multiple options have the same value. Also the `SelectItem` contained so weird recursive structures that are impossible to create with HTML. So I refactored `SelectItem` as a variant, and gave the options a unique id. The id is send back to `HTMLSelectElement` so it can find out exactly which option element is selected.
2024-04-03 19:19:08 +02:00
virtual void select_dropdown_closed(u64 page_id, Optional<u32> const& selected_item_id) override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
virtual void toggle_media_play_state(u64 page_id) override;
virtual void toggle_media_mute_state(u64 page_id) override;
virtual void toggle_media_loop_state(u64 page_id) override;
virtual void toggle_media_controls_state(u64 page_id) override;
LibWeb+LibWebView+WebContent: Support muting an entire page This adds an IPC for chromes to mute a tab. When muted, we trigger an internal volume change notification and indicate that the user agent has overriden the media volume.
2024-03-30 09:41:15 -04:00
virtual void toggle_page_mute_state(u64 page_id) override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
virtual void set_user_style(u64 page_id, String const&) override;
virtual void enable_inspector_prototype(u64 page_id) override;
virtual void take_document_screenshot(u64 page_id) override;
virtual void take_dom_node_screenshot(u64 page_id, i32 node_id) override;
LibWebView+WebContent+headless-browser: Make the page info IPCs async The IPCs to request a page's text, layout tree, etc. are currently all synchronous. This can result in a deadlock when WebContent also makes a synchronous IPC call, as both ends will be waiting on each other. This replaces the page info IPCs with a single, asynchronous IPC. This new IPC is promise-based, much like our screenshot IPC.
2024-09-19 10:40:00 -04:00
virtual void request_internal_page_info(u64 page_id, WebView::PageInfoType) override;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
virtual Messages::WebContentServer::GetLocalStorageEntriesResponse get_local_storage_entries(u64 page_id) override;
virtual Messages::WebContentServer::GetSessionStorageEntriesResponse get_session_storage_entries(u64 page_id) override;
virtual Messages::WebContentServer::GetSelectedTextResponse get_selected_text(u64 page_id) override;
virtual void select_all(u64 page_id) override;
LibWeb+LibWebView+WebContent: Support case-insensitive find-in-page This allows searching for text with case-insensitivity. As this is probably what most users expect, the default behavior is changes to perform case-insensitive lookups. Chromes may add UI to change the behavior as they see fit.
2024-05-31 16:01:34 -04:00
virtual void find_in_page(u64 page_id, String const& query, CaseSensitivity) override;
LibWeb+LibWebView+WebContent: Add basic find in page functionality This allows the browser to send a query to the WebContent process, which will search the page for the given string and highlight any occurrences of that string.
2024-05-29 20:09:33 +01:00
virtual void find_in_page_next_match(u64 page_id) override;
virtual void find_in_page_previous_match(u64 page_id) override;
LibWeb+WebContent+Ladybird: Add ability to paste text from clipboard Text can be pasted by pressing Ctrl/Cmd+V or by using button in the context menu. For now only the Qt client is supported.
2024-03-22 11:56:49 +01:00
virtual void paste(u64 page_id, String const& text) override;
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
virtual void system_time_zone_changed() override;
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
void report_finished_handling_input_event(u64 page_id, Web::EventResult event_was_handled);
LibWebView+WebContent: Propagate unconsumed input events out of OOPWV Since 9e2bd9d261a8c0c1b5eeafde95ca310efc667204, the OOPWV has been consuming all mouse and keyboard events, preventing action shortcuts from working. So let's fix that. :^) OOPWV now queues up input events, sending them one at a time to the WebContent process and waiting for the new `did_finish_handling_input_event(bool event_was_accepted) =|` IPC call before sending the next one. If the event was not accepted, OOPWV imitates the usual event bubbling: first passing the event to its superclass, then to its parent widget, and finally propagating to any Action shortcuts. With this, shortcuts like Ctrl+I to open Browser's JS console work again, except when a contenteditable field is selected. That's a whole separate stack of yaks. Co-authored-by: Zaggy1024 <zaggy1024@gmail.com>
2022-11-21 16:07:47 +00:00
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
NonnullOwnPtr<PageHost> m_page_host;
LibWeb+WebContent: Use anonymous files for OOPWV backing stores To support this, the GUI process and the WebContent service will now coordinate their backing store bitmaps. Each backing store can be referred to by a serial ID, and we don't need to keep resending it as a file descriptor. We should probably do something similar in WindowServer. :^)
2021-01-16 23:15:32 +01:00
LibWeb+WebContent: Do not reference-count file request objects There is currently a memory leak with these file request objects due to the callback on_file_request_finish referencing itself in its capture list. This object does not need to be reference counted or allocated on the heap. It is only ever stored in a HashMap until a response is received from the browser, and it is not shared.
2023-01-30 16:35:47 -05:00
HashMap<int, Web::FileRequest> m_requested_files {};
Browser+LibWeb+WebContent: Allow Browser to load local files To achieve this goal: - The Browser unveils "/tmp/portal/filesystemaccess" - Pass the page through LoadRequest => ResourceLoader - ResourceLoader requests a file to the FileSystemAccessServer via IPC - OutOfProcessWebView handles it and sends a file descriptor back to the Page.
2022-02-26 17:50:31 +01:00
int last_id { 0 };
WebContent: Give paint requests a chance to happen between input events Before this patch, we had an issue where the WebContent process could get backed up with tons of pending input events (especially mouse moves) and have to work through all of those before responding to a paint request from the UI process. This could lead to a situation where we went for a very long time without seeing any visual updates. The approach I've taken here is pretty simple, we basically make a queue of all incoming input events on the WebContent process side, and then process that queue one event at a time, using a zero timer. This is basic, but it allows paint requests to come in between the input events and we do now get more frequent visual updates even during heavy pressure from input events.
2023-03-14 13:26:06 +01:00
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
struct QueuedInputEvent {
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
u64 page_id { 0 };
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
Web::InputEvent event;
size_t coalesced_event_count { 0 };
WebContent: Give paint requests a chance to happen between input events Before this patch, we had an issue where the WebContent process could get backed up with tons of pending input events (especially mouse moves) and have to work through all of those before responding to a paint request from the UI process. This could lead to a situation where we went for a very long time without seeing any visual updates. The approach I've taken here is pretty simple, we basically make a queue of all incoming input events on the WebContent process side, and then process that queue one event at a time, using a zero timer. This is basic, but it allows paint requests to come in between the input events and we do now get more frequent visual updates even during heavy pressure from input events.
2023-03-14 13:26:06 +01:00
};
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
void enqueue_input_event(QueuedInputEvent);
WebContent: Give paint requests a chance to happen between input events Before this patch, we had an issue where the WebContent process could get backed up with tons of pending input events (especially mouse moves) and have to work through all of those before responding to a paint request from the UI process. This could lead to a situation where we went for a very long time without seeing any visual updates. The approach I've taken here is pretty simple, we basically make a queue of all incoming input events on the WebContent process side, and then process that queue one event at a time, using a zero timer. This is basic, but it allows paint requests to come in between the input events and we do now get more frequent visual updates even during heavy pressure from input events.
2023-03-14 13:26:06 +01:00
void process_next_input_event();
LibWebView+WebContent: Use Web::InputEvent for WebContent input IPC Now that all input events are handled by LibWebView, replace the IPCs which send the fields of Web::KeyEvent / Web::MouseEvent individually with one IPC per event type (key or mouse). We can also replace the ad-hoc queued input structure with a smaller struct that simply holds the tranferred Web::KeyEvent / Web::MouseEvent. In the future, we can also adapt Web::EventHandler to use these structs.
2024-03-05 17:06:32 -05:00
Queue<QueuedInputEvent> m_input_event_queue;
WebContent: Give paint requests a chance to happen between input events Before this patch, we had an issue where the WebContent process could get backed up with tons of pending input events (especially mouse moves) and have to work through all of those before responding to a paint request from the UI process. This could lead to a situation where we went for a very long time without seeing any visual updates. The approach I've taken here is pretty simple, we basically make a queue of all incoming input events on the WebContent process side, and then process that queue one event at a time, using a zero timer. This is basic, but it allows paint requests to come in between the input events and we do now get more frequent visual updates even during heavy pressure from input events.
2023-03-14 13:26:06 +01:00
RefPtr<Web::Platform::Timer> m_input_event_queue_timer;
WebContent: Start work on browser process separation :^) The "WebContent" service provides a very restricted instance of LibWeb running as an unprivileged user account. This will be used to implement process separation in Browser, among other things. This first cut of the service only spawns a single WebContent process when someone connects to /tmp/portal/webcontent. We will soon switch this over to spawning a new process for each connection. Since this feature is very immature, we'll be bringing it up inside of Demos/WebView as a separate demo program. Eventually this will become a reusable widget that anyone can embed and easily get out-of-process web content in their GUI. This is pretty, pretty cool! :^)
2020-06-17 17:31:42 +02:00
};
}
Reference in a new issue Copy permalink