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/Libraries/LibWebView/ViewImplementation.h

236 lines
9.5 KiB
C
Raw Normal View History

LibWebView: Add abstract virtual base for WebView implementations This patch adds WebView::ViewImplementation with all the `notify_server_did_this_or_that()` functions from OOPWV. This will allow us to share code between different web views, paving the way for a Qt widget in Ladybird that can talk to a WebContent process.
2022-10-05 14:32:17 +02:00
/*
* Copyright (c) 2022, Andreas Kling <kling@serenityos.org>
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
* Copyright (c) 2023, Linus Groh <linusg@serenityos.org>
LibWebView: Add abstract virtual base for WebView implementations This patch adds WebView::ViewImplementation with all the `notify_server_did_this_or_that()` functions from OOPWV. This will allow us to share code between different web views, paving the way for a Qt widget in Ladybird that can talk to a WebContent process.
2022-10-05 14:32:17 +02:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Forward.h>
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 12:37:31 -04:00
#include <AK/Function.h>
LibWebView: Log the result of taking screenshots to Inspector's console It probably isn't obvious that screenshots are saved to the user's Downloads folder, so add a console message to inform them.
2023-12-09 16:57:57 -05:00
#include <AK/LexicalPath.h>
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
#include <AK/String.h>
LibWebView: Add abstract virtual base for WebView implementations This patch adds WebView::ViewImplementation with all the `notify_server_did_this_or_that()` functions from OOPWV. This will allow us to share code between different web views, paving the way for a Qt widget in Ladybird that can talk to a WebContent process.
2022-10-05 14:32:17 +02:00
#include <LibGfx/Forward.h>
#include <LibGfx/StandardCursor.h>
#include <LibWeb/Forward.h>
WebContent+Everywhere: Add an option to not activate new tabs over IPC WebDriver, for example, will want to create new tabs without activating them.
2023-03-20 18:39:20 -04:00
#include <LibWeb/HTML/ActivateTab.h>
Ladybird+LibWeb: Add basic select element support
2023-12-07 15:53:49 +01:00
#include <LibWeb/HTML/SelectItem.h>
LibWebView: Add abstract virtual base for WebView implementations This patch adds WebView::ViewImplementation with all the `notify_server_did_this_or_that()` functions from OOPWV. This will allow us to share code between different web views, paving the way for a Qt widget in Ladybird that can talk to a WebContent process.
2022-10-05 14:32:17 +02:00
#include <LibWebView/Forward.h>
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
#include <LibWebView/WebContentClient.h>
LibWebView: Add abstract virtual base for WebView implementations This patch adds WebView::ViewImplementation with all the `notify_server_did_this_or_that()` functions from OOPWV. This will allow us to share code between different web views, paving the way for a Qt widget in Ladybird that can talk to a WebContent process.
2022-10-05 14:32:17 +02:00
namespace WebView {
class ViewImplementation {
public:
virtual ~ViewImplementation() { }
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
struct DOMNodeProperties {
String computed_style_json;
String resolved_style_json;
String custom_properties_json;
String node_box_sizing_json;
Browser+LibWebView: Load and Display ARIA Properites and State The inspector widget now has a new ARIA tab which displays an individual element's ARIA properties and state. The view itself is pretty basic for now, just being a table- there is definitely room for some better UX here but it's enough for a first cut.
2023-05-21 08:52:03 -05:00
String aria_properties_state_json;
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
};
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 12:37:31 -04:00
void set_url(Badge<WebContentClient>, AK::URL url) { m_url = move(url); }
LibWebView+Ladybird: Move page loading to ViewImplementation
2023-01-12 20:30:06 +00:00
AK::URL const& url() const { return m_url; }
LibWebView: Add window handle in `ClientState` in `ViewImplementation` Add field for a handle that is going to be used by WebDriver to identify top-level browsing contexts. It is supposed to be populated by WebContent client during creation. Co-authored-by: Timothy Flynn <trflynn89@pm.me>
2023-03-16 18:24:30 +03:00
String const& handle() const { return m_client_state.client_handle; }
Ladybird+LibWebView: Move most of paint handling to LibWebView Storing the backup bitmap is the same across Browser and Ladybird. Just peform that work in LibWebView, and handle only the implementation- specific nuances within the browsers.
2023-05-20 10:50:05 -04:00
void server_did_paint(Badge<WebContentClient>, i32 bitmap_id, Gfx::IntSize size);
Ladybird+LibWebView: Move APIs which only repaint to LibWebView We can easily add hooks to notify the browsers of these events if any implementation-specific handling is needed in the future, but for now, these only repaint the client, which we can do in ViewImplementation.
2023-05-20 11:04:02 -04:00
void server_did_invalidate_content_rect(Badge<WebContentClient>, Gfx::IntRect rect);
void server_did_change_selection(Badge<WebContentClient>);
Ladybird+LibWebView: Move most of paint handling to LibWebView Storing the backup bitmap is the same across Browser and Ladybird. Just peform that work in LibWebView, and handle only the implementation- specific nuances within the browsers.
2023-05-20 10:50:05 -04:00
LibWebView+Ladybird: Move page loading to ViewImplementation
2023-01-12 20:30:06 +00:00
void load(AK::URL const&);
Userland+Ladybird: Always specify url to be about:srcdoc in load_html() After moving to navigables, we started reusing the code that populates session history entries with the srcdoc attribute value from iframes in `Page::load_html()` for loading HTML. This change addresses a crash in `determine_the_origin` which occurred because this method expected the URL to be `about:srcdoc` if we also provided HTML content (previously, it was the URL passed along with the HTML content into `load_html()`).
2023-09-17 17:12:17 +02:00
void load_html(StringView);
LibWebView+Ladybird: Move page loading to ViewImplementation
2023-01-12 20:30:06 +00:00
void load_empty_document();
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
void zoom_in();
void zoom_out();
void reset_zoom();
LibWebView: Expose getter for current zoom level
2023-03-26 19:41:56 +01:00
float zoom_level() const { return m_zoom_level; }
Ladybird/Qt: Open context menus at requested position
2023-12-12 22:33:36 +01:00
float device_pixel_ratio() const { return m_device_pixel_ratio; }
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
LibWebView+Ladybird: Move preferred color scheme to ViewImplementation
2023-01-12 20:44:42 +00:00
void set_preferred_color_scheme(Web::CSS::PreferredColorScheme);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString selected_text();
LibWebView: Add a helper to get selected text with collapsed whitespace
2023-10-23 16:52:57 -04:00
Optional<String> selected_text_with_whitespace_collapsed();
LibWebView+Ladybird: Move text selection to ViewImplementation
2023-01-12 20:42:42 +00:00
void select_all();
LibWebView+Ladybird: Move get source request to ViewImplementation
2023-01-12 19:58:00 +00:00
void get_source();
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
void inspect_dom_tree();
void inspect_accessibility_tree();
LibWeb: Wrap PseudoElements stored in SimpleSelector in a class No functional impact intended. This is just a more complicated way of writing what we have now. The goal of this commit is so that we are able to store the 'name' of a pseudo element for use in serializing 'unknown -webkit- pseudo-elements', see: https://www.w3.org/TR/selectors-4/#compat This is quite awkward, as in pretty much all cases just the selector type enum is enough, but we will need to cache the name for serializing these unknown selectors. I can't figure out any reason why we would need this name anywhere else in the engine, so pretty much everywhere is still just passing around this raw enum. But this change will allow us to easily store the name inside of this new struct for when it is needed for serialization, once those webkit unknown elements are supported by our engine.
2023-12-10 21:00:03 +13:00
ErrorOr<DOMNodeProperties> inspect_dom_node(i32 node_id, Optional<Web::CSS::Selector::PseudoElement::Type> pseudo_element);
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
void clear_inspected_dom_node();
i32 get_hovered_node_id();
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
void set_dom_node_text(i32 node_id, String text);
Optional<i32> set_dom_node_tag(i32 node_id, String name);
LibWebView+WebContent: Add a WebContent IPC to add DOM attributes
2023-12-05 16:49:47 -05:00
void add_dom_node_attributes(i32 node_id, Vector<Attribute> attributes);
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
void replace_dom_node_attribute(i32 node_id, String name, Vector<Attribute> replacement_attributes);
LibWebView+WebContent: Add WebContent IPC to create children DOM nodes This adds IPC to create append a child <div> element or a text node to a DOM node.
2023-12-07 11:00:57 -05:00
Optional<i32> create_child_element(i32 node_id);
Optional<i32> create_child_text_node(i32 node_id);
LibWebView+WebContent: Add a WebContent IPC to clone a DOM node
2023-12-07 11:12:43 -05:00
Optional<i32> clone_dom_node(i32 node_id);
LibWebView+WebContent: Add a WebContent IPC to remove a DOM node The FIXME added to ConnectionFromClient::remove_dom_node is copied from Web::EditEventHandler. The same behavior is observed here, with many lingering Layout::TextNodes, for example.
2023-12-05 14:59:54 -05:00
void remove_dom_node(i32 node_id);
LibWebView+WebContent: Add a WebContent IPC to get a DOM node's HTML
2023-12-06 10:36:27 -05:00
Optional<String> get_dom_node_html(i32 node_id);
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
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
void debug_request(ByteString const& request, ByteString const& argument = {});
LibWebView+Ladybird: Move debug request to ViewImplementation
2023-01-12 20:34:08 +00:00
LibWebView+Ladybird: Move running JavaScript to ViewImplementation
2023-01-12 20:39:08 +00:00
void run_javascript(StringView);
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
void js_console_input(ByteString const& js_source);
Ladybird: Move ownership of the JS console/inspector to the tab object This is to match Browser, where ownership of all "subwidgets" is placed on the tab as well. This further lets us align the web view callbacks to match Browser's OOPWV as well, which will later let us move them into the base LibWebView class.
2023-05-17 11:54:36 -04:00
void js_console_request_messages(i32 start_index);
LibWebView+Ladybird: Move running JavaScript to ViewImplementation
2023-01-12 20:39:08 +00:00
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
void alert_closed();
void confirm_closed(bool accepted);
void prompt_closed(Optional<String> response);
LibWeb+LibWebView+WebContent: Add support for <input type="color"> This commit introduces 3 things: - Support for the color type in HTMLInputElement itself - A mechanism for handling non event loop blocking dialogs in Page - The associated plumbing up to ViewImplementation Frontends may add support for the color picker with the ViewImplementation.on_request_color_picker function
2023-09-04 11:32:40 +02:00
void color_picker_closed(Optional<Color> picked_color);
Ladybird+LibWeb: Add basic select element support
2023-12-07 15:53:49 +01:00
void select_dropdown_closed(Optional<String> value);
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
Ladybird+LibWeb+WebContent: Generalize video context menus for all media The data we want to send out of the WebContent process is identical for audio and video elements. Rather than just duplicating all of this for audio, generalize the names used for this IPC for all media elements. This also encapsulates that data into a struct. This makes adding new fields to be sent much easier (such as an upcoming field for muting the element).
2023-06-16 10:51:38 -04:00
void toggle_media_play_state();
Ladybird+LibWeb+WebContent: Add context menu controls for muting audio
2023-06-16 11:29:54 -04:00
void toggle_media_mute_state();
Ladybird+LibWeb+WebContent: Generalize video context menus for all media The data we want to send out of the WebContent process is identical for audio and video elements. Rather than just duplicating all of this for audio, generalize the names used for this IPC for all media elements. This also encapsulates that data into a struct. This makes adding new fields to be sent much easier (such as an upcoming field for muting the element).
2023-06-16 10:51:38 -04:00
void toggle_media_loop_state();
void toggle_media_controls_state();
LibWeb+WebContent: Add APIs to control video playback state This allows for the browser process to control the play/pause state, whether we paint user agent controls on the video, and whether the video loops when it finishes playing.
2023-05-15 11:17:58 -04:00
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
enum class ScreenshotType {
Visible,
Full,
};
LibWebView: Log the result of taking screenshots to Inspector's console It probably isn't obvious that screenshots are saved to the user's Downloads folder, so add a console message to inform them.
2023-12-09 16:57:57 -05:00
ErrorOr<LexicalPath> take_screenshot(ScreenshotType);
ErrorOr<LexicalPath> take_dom_node_screenshot(i32);
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
LibJS+LibWebView+WebContent+Ladybird: Output GC-graph into a file Instead of displaying a massive JSON in stdout, it's more practical to save the GC-graph to a file.
2023-12-12 13:25:06 +01:00
ErrorOr<LexicalPath> dump_gc_graph();
LibWebView: Allow using native/user style sheets on Lagom Move the methods to set the native/user style sheets to the base ViewImplementation class. We must also generate the native style sheet explicitly for now, as LibWebView on Lagom isn't able to include the main LibWebView CMakeLists.txt file yet.
2023-08-26 13:34:59 -04:00
void set_user_style_sheet(String source);
// Load Native.css as the User style sheet, which attempts to make WebView content look as close to
// native GUI widgets as possible.
void use_native_user_style_sheet();
LibWeb+LibWebView+WebContent: Add an Inspector IDL object to the Window This is an internal object that must be explicitly enabled by the chrome before it is added to the Window. The Inspector object will be used by a special WebView that will replace all chrome-specific inspector windows. The IDL defines methods that this WebView will need to inform the chrome of various events, such as the user clicking a DOM node.
2023-11-23 12:22:23 -05:00
void enable_inspector_prototype();
Ladybird+LibWebView: Migrate layout notification to LibWebView callbacks
2023-08-23 10:33:26 -04:00
Function<void(Gfx::IntSize)> on_did_layout;
Ladybird+LibWebView: Move most of paint handling to LibWebView Storing the backup bitmap is the same across Browser and Ladybird. Just peform that work in LibWebView, and handle only the implementation- specific nuances within the browsers.
2023-05-20 10:50:05 -04:00
Function<void()> on_ready_to_paint;
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 12:37:31 -04:00
Function<String(Web::HTML::ActivateTab)> on_new_tab;
Function<void()> on_activate_tab;
Function<void()> on_close;
Function<void(Gfx::IntPoint screen_position)> on_context_menu_request;
Function<void(const AK::URL&, Gfx::IntPoint screen_position)> on_link_context_menu_request;
Function<void(const AK::URL&, Gfx::IntPoint screen_position, Gfx::ShareableBitmap const&)> on_image_context_menu_request;
Ladybird+LibWeb+WebContent: Generalize video context menus for all media The data we want to send out of the WebContent process is identical for audio and video elements. Rather than just duplicating all of this for audio, generalize the names used for this IPC for all media elements. This also encapsulates that data into a struct. This makes adding new fields to be sent much easier (such as an upcoming field for muting the element).
2023-06-16 10:51:38 -04:00
Function<void(Gfx::IntPoint screen_position, Web::Page::MediaContextMenu const&)> on_media_context_menu_request;
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 12:37:31 -04:00
Function<void(const AK::URL&)> on_link_hover;
Function<void()> on_link_unhover;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
Function<void(const AK::URL&, ByteString const& target, unsigned modifiers)> on_link_click;
Function<void(const AK::URL&, ByteString const& target, unsigned modifiers)> on_link_middle_click;
Function<void(ByteString const&)> on_title_change;
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 12:37:31 -04:00
Function<void(const AK::URL&, bool)> on_load_start;
Function<void(const AK::URL&)> on_load_finish;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
Function<void(ByteString const& path, i32)> on_request_file;
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 12:37:31 -04:00
Function<void()> on_navigate_back;
Function<void()> on_navigate_forward;
Function<void()> on_refresh;
Function<void(Gfx::Bitmap const&)> on_favicon_change;
Ladybird+LibWebView: Migrate scrolling changes to LibWebView callbacks
2023-08-23 10:57:09 -04:00
Function<void(i32, i32)> on_scroll_by_delta;
Function<void(Gfx::IntPoint)> on_scroll_to_point;
Ladybird+LibWebView: Migrate cursor changes to LibWebView callbacks
2023-08-23 10:43:27 -04:00
Function<void(Gfx::StandardCursor)> on_cursor_change;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
Function<void(Gfx::IntPoint, ByteString const&)> on_enter_tooltip_area;
Ladybird+LibWebView: Migrate tooltip changes to LibWebView callbacks
2023-08-23 11:11:39 -04:00
Function<void()> on_leave_tooltip_area;
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
Function<void(String const& message)> on_request_alert;
Function<void(String const& message)> on_request_confirm;
Function<void(String const& message, String const& default_)> on_request_prompt;
Function<void(String const& message)> on_request_set_prompt_text;
Function<void()> on_request_accept_dialog;
Function<void()> on_request_dismiss_dialog;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
Function<void(const AK::URL&, ByteString const&)> on_received_source;
Function<void(ByteString const&)> on_received_dom_tree;
Function<void(ByteString const&)> on_received_accessibility_tree;
Ladybird+LibWebView: Rename some "on get" notifications to "on received" The old names sounded like awkward English to me, as they implied the WebContent process is asking for information. In reality, WebContent is *providing* the information.
2023-08-23 11:25:24 -04:00
Function<void(i32 message_id)> on_received_console_message;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
Function<void(i32 start_index, Vector<ByteString> const& message_types, Vector<ByteString> const& messages)> on_received_console_messages;
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 12:37:31 -04:00
Function<Vector<Web::Cookie::Cookie>(AK::URL const& url)> on_get_all_cookies;
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
Function<Optional<Web::Cookie::Cookie>(AK::URL const& url, ByteString const& name)> on_get_named_cookie;
Function<ByteString(const AK::URL& url, Web::Cookie::Source source)> on_get_cookie;
Browser+Ladybird+LibWebView: Handle trivial content APIs in LibWebView The goal here is to reduce the amount of WebContent client APIs that are duplicated across every ViewImplementation. Across our three browsers, we currently: Ladybird - Mix some AK::Function callbacks and Qt signals to notify tabs of WebContent events. Browser - Use only AK::Function callbacks. headless-browser - Drop most events on the floor. Instead, let's only use AK::Function callbacks across all three browsers to propagate events to tabs. This allows us to invoke those callbacks directly from LibWebView instead of all three browsers needing to define a trivial `if (callback) callback();` override of a LibWebView virtual function. For headless-browser, we can simply not set these callbacks. As a first pass, this only converts WebContent events that are trivial to this approach. That is, events that were simply passed onto the tab or handled without much fuss.
2023-05-17 12:37:31 -04:00
Function<void(const AK::URL& url, Web::Cookie::ParsedCookie const& cookie, Web::Cookie::Source source)> on_set_cookie;
Function<void(Web::Cookie::Cookie const& cookie)> on_update_cookie;
Function<void(i32 count_waiting)> on_resource_status_change;
Function<void()> on_restore_window;
Function<Gfx::IntPoint(Gfx::IntPoint)> on_reposition_window;
Function<Gfx::IntSize(Gfx::IntSize)> on_resize_window;
Function<Gfx::IntRect()> on_maximize_window;
Function<Gfx::IntRect()> on_minimize_window;
Function<Gfx::IntRect()> on_fullscreen_window;
LibWeb+LibWebView+WebContent: Add support for <input type="color"> This commit introduces 3 things: - Support for the color type in HTMLInputElement itself - A mechanism for handling non event loop blocking dialogs in Page - The associated plumbing up to ViewImplementation Frontends may add support for the color picker with the ViewImplementation.on_request_color_picker function
2023-09-04 11:32:40 +02:00
Function<void(Color current_color)> on_request_color_picker;
Ladybird+LibWeb: Add basic select element support
2023-12-07 15:53:49 +01:00
Function<void(Gfx::IntPoint content_position, i32 minimum_width, Vector<Web::HTML::SelectItem> items)> on_request_select_dropdown;
Ladybird+LibWebView: Migrate input completions to LibWebView callbacks
2023-08-23 11:19:21 -04:00
Function<void(bool)> on_finish_handling_input_event;
LibWeb+WebContent+headless-browser: Support async text tests Previously, we used `on_load_finish` to determine when the text test was completed. This method did not allow testing of async functions because there was no way to indicate that the runner should wait for the async call to end. This change introduces a function in the `internals` object that is intended to be called when the text test execution is completed. The text test runner will now ignore `on_load_finish` which means a test will timeout if this new function is never called. `test(f)` function in `include.js` has been modified to automatically terminate a test once `load` event is fired on `window`. new `asyncTest(f)` function has been introduces. `f` receives function that will terminate a test as a first argument. Every test is expected to call either `test()` or `asyncTest()` to complete. If not, it will remain hanging until a timeout occurs.
2023-09-14 19:17:32 +02:00
Function<void()> on_text_test_finish;
LibWeb+LibWebView+WebContent: Add support for meta theme-color
2023-09-19 01:51:48 +02:00
Function<void(Gfx::Color)> on_theme_color_change;
LibWebView+WebContent: Add an IPC hook to insert data into the clipboard
2023-11-10 13:35:41 -05:00
Function<void(String const&, String const&, String const&)> on_insert_clipboard_entry;
LibWeb+LibWebView+WebContent: Add an Inspector IDL object to the Window This is an internal object that must be explicitly enabled by the chrome before it is added to the Window. The Inspector object will be used by a special WebView that will replace all chrome-specific inspector windows. The IDL defines methods that this WebView will need to inform the chrome of various events, such as the user clicking a DOM node.
2023-11-23 12:22:23 -05:00
Function<void()> on_inspector_loaded;
LibWeb: Wrap PseudoElements stored in SimpleSelector in a class No functional impact intended. This is just a more complicated way of writing what we have now. The goal of this commit is so that we are able to store the 'name' of a pseudo element for use in serializing 'unknown -webkit- pseudo-elements', see: https://www.w3.org/TR/selectors-4/#compat This is quite awkward, as in pretty much all cases just the selector type enum is enough, but we will need to cache the name for serializing these unknown selectors. I can't figure out any reason why we would need this name anywhere else in the engine, so pretty much everywhere is still just passing around this raw enum. But this change will allow us to easily store the name inside of this new struct for when it is needed for serialization, once those webkit unknown elements are supported by our engine.
2023-12-10 21:00:03 +13:00
Function<void(i32, Optional<Web::CSS::Selector::PseudoElement::Type> const&)> on_inspector_selected_dom_node;
LibWeb+LibWebView+WebContent: Add Inspector IPCs to manipulate DOM nodes This adds the IDL methods and IPC to forward DOM-editing events from the Inspector WebView to the Inspector client.
2023-12-03 11:49:08 -05:00
Function<void(i32, String const&)> on_inspector_set_dom_node_text;
Function<void(i32, String const&)> on_inspector_set_dom_node_tag;
LibWeb+LibWebView+WebContent: Add an Inspector IPC to add DOM attributes
2023-12-05 16:43:14 -05:00
Function<void(i32, Vector<Attribute> const&)> on_inspector_added_dom_node_attributes;
LibWeb+LibWebView+WebContent: Add Inspector IPCs to manipulate DOM nodes This adds the IDL methods and IPC to forward DOM-editing events from the Inspector WebView to the Inspector client.
2023-12-03 11:49:08 -05:00
Function<void(i32, String const&, Vector<Attribute> const&)> on_inspector_replaced_dom_node_attribute;
LibWeb+LibWebView+WebContent: Separate tag/attribute in Inspector menu It was a bit short-sighted to combine the tag and attribute names into one string when the Inspector requests a context menu. We will want both values for some context menu actions. Send both names, as well as the attribute value, when requesting the context menu.
2023-12-06 09:34:53 -05:00
Function<void(i32, Gfx::IntPoint, String const&, Optional<String> const&, Optional<Attribute> const&)> on_inspector_requested_dom_tree_context_menu;
LibWeb+LibWebView+WebContent: Add an Inspector IPC to execute JavaScript The Inspector will have an <input> element to execute user-provided JS. This adds an IDL method and IPC to forward that JS from the Inspector WebView to the Inspector client.
2023-11-30 19:27:32 -05:00
Function<void(String const&)> on_inspector_executed_console_script;
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
LibWeb: Refactor int types in WebContentServer to DevicePixels
2023-12-14 07:17:00 +01:00
virtual Web::DevicePixelRect viewport_rect() const = 0;
Browser+Ladybird+LibWebView: Virtualize computing content/widget points This will allow moving some copy-pasted functionality from web view implementations to the base LibWebView class.
2023-05-17 10:12:13 -04:00
virtual Gfx::IntPoint to_content_position(Gfx::IntPoint widget_position) const = 0;
virtual Gfx::IntPoint to_widget_position(Gfx::IntPoint content_position) const = 0;
Ladybird+LibWebView: Move backing store management code to LibWebView This lets us share this code on all platforms, and makes resizing the window much faster on SerenityOS as well. :^)
2023-05-15 07:59:51 +02:00
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
protected:
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
static constexpr auto ZOOM_MIN_LEVEL = 0.3f;
static constexpr auto ZOOM_MAX_LEVEL = 5.0f;
static constexpr auto ZOOM_STEP = 0.1f;
Ladybird+LibWebView+Browser: Remove ability to run with AST interpreter
2023-08-07 16:44:20 +02:00
ViewImplementation();
Ladybird+LibWebView: Move backing store management code to LibWebView This lets us share this code on all platforms, and makes resizing the window much faster on SerenityOS as well. :^)
2023-05-15 07:59:51 +02:00
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
WebContentClient& client();
WebContentClient const& client() const;
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
virtual void update_zoom() = 0;
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
Ladybird+LibWebView: Move backing store management code to LibWebView This lets us share this code on all platforms, and makes resizing the window much faster on SerenityOS as well. :^)
2023-05-15 07:59:51 +02:00
enum class WindowResizeInProgress {
No,
Yes,
};
void resize_backing_stores_if_needed(WindowResizeInProgress);
void request_repaint();
void handle_resize();
Ladybird+LibWebView: Move options used to launch WebContent to a struct It is currently a bit messy to pass these options along from main() to where WebContent is actually launched. If a new flag were to be added, there are a couple dozen files that need to be updated to pass that flag along. With this change, the flag can just be added to the struct, set in main(), and handled in launch_web_content_process().
2023-12-01 12:18:40 -05:00
virtual void create_client() { }
Ladybird+LibWebView: Add -P/--enable-callgrind-profiling option This adds a -P option to run Ladybird under callgrind. It starts with instrumentation disabled. To start capturing a profile (once Ladybird has launched) run `callgrind_control -i on` and to stop it again run `callgrind_control -i off`. P.s. This is pretty much stolen from Andreas (and is based on the patch everyone [that wants a profile] have been manually applying).
2023-04-15 01:04:28 +01:00
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
void handle_web_content_process_crash();
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
struct SharedBitmap {
i32 id { -1 };
i32 pending_paints { 0 };
LibWeb: Refactor int types in WebContentServer to DevicePixels
2023-12-14 07:17:00 +01:00
Web::DevicePixelSize last_painted_size;
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
RefPtr<Gfx::Bitmap> bitmap;
};
struct ClientState {
RefPtr<WebContentClient> client;
LibWebView: Add window handle in `ClientState` in `ViewImplementation` Add field for a handle that is going to be used by WebDriver to identify top-level browsing contexts. It is supposed to be populated by WebContent client during creation. Co-authored-by: Timothy Flynn <trflynn89@pm.me>
2023-03-16 18:24:30 +03:00
String client_handle;
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
SharedBitmap front_bitmap;
SharedBitmap back_bitmap;
i32 next_bitmap_id { 0 };
bool has_usable_bitmap { false };
bool got_repaint_requests_while_painting { false };
} m_client_state;
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
LibWebView+Ladybird: Move page loading to ViewImplementation
2023-01-12 20:30:06 +00:00
AK::URL m_url;
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
float m_zoom_level { 1.0 };
float m_device_pixel_ratio { 1.0 };
Ladybird+LibWebView: Move backing store management code to LibWebView This lets us share this code on all platforms, and makes resizing the window much faster on SerenityOS as well. :^)
2023-05-15 07:59:51 +02:00
RefPtr<Core::Timer> m_backing_store_shrink_timer;
RefPtr<Gfx::Bitmap> m_backup_bitmap;
LibWeb: Refactor int types in WebContentServer to DevicePixels
2023-12-14 07:17:00 +01:00
Web::DevicePixelSize m_backup_bitmap_size;
LibWebView: Don't re-create WebContent proceses when repeatedly crashing Serenity handles this in the SystemServer already, but the simplest place to put this logic is the ViewImplementation base class. This is trivial to see when running Ladybird without SERENTIY_SOURCE_DIR set, or set improperly.
2023-05-27 10:46:45 -06:00
size_t m_crash_count = 0;
RefPtr<Core::Timer> m_repeated_crash_timer;
LibWebView: Add abstract virtual base for WebView implementations This patch adds WebView::ViewImplementation with all the `notify_server_did_this_or_that()` functions from OOPWV. This will allow us to share code between different web views, paving the way for a Qt widget in Ladybird that can talk to a WebContent process.
2022-10-05 14:32:17 +02:00
};
}
Reference in a new issue Copy permalink