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

406 lines
12 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
/*
LibWeb+WebContent: Support window.confirm() in OOPWV
2021-02-10 08:48:28 +01:00
* Copyright (c) 2020-2021, Andreas Kling <kling@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
*/
#include "WebContentClient.h"
LibWebView: Replace OOPWV inclusion with ViewImplementation.h This is the header WebContentClient actually needs. Just noticed by clangd when OOPWV.h has errors that don't apply to WebContentClient at all.
2023-05-20 10:52:02 -04:00
#include "ViewImplementation.h"
Everywhere: Replace a bundle of dbg with dbgln. These changes are arbitrarily divided into multiple commits to make it easier to find potentially introduced bugs with git bisect.
2021-01-17 16:57:17 +01:00
#include <AK/Debug.h>
Browser+LibWeb+WebContent: Parse cookies in the OOP tab To protect the main Browser process against nefarious cookies, parse the cookies out-of-process and then send the parsed result over IPC to the main process. This way, if the cookie parser blows up, only that tab will be affected.
2021-04-15 10:36:20 -04:00
#include <LibWeb/Cookie/ParsedCookie.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
LibWebView: Move OutOfProcessWebView to a new LibWebView library Also moves WebContentClient and the references to the generated IPC descriptions, since they are all components of OutOfProcessWebView. This patch has no functional changes.
2022-04-30 10:46:33 +02:00
namespace WebView {
LibWeb: Move OutOfProcessWebView into the Web namespace
2020-08-24 15:33:18 +04:30
LibCore: Move Stream-based sockets into the `Core` namespace
2023-02-08 23:05:44 +01:00
WebContentClient::WebContentClient(NonnullOwnPtr<Core::LocalSocket> socket, ViewImplementation& view)
Userland: Rename IPC::ServerConnection=>IPC::ConnectionToServer This was done with CLion's automatic rename feature.
2022-02-25 12:27:37 +02:00
: IPC::ConnectionToServer<WebContentClientEndpoint, WebContentServerEndpoint>(*this, move(socket))
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
, m_view(view)
{
}
LibWeb: Handle WebContent process crashes gracefully :^) The OOPWV will now detect WebContent process crashes/disconnections and simply create a new WebContent process in its place. We also generate a little error page with a link to the crashing URL so you can reload and try again. This a huge step forward for OOPWV since it now has a feature that IPWV can never replicate. :^)
2021-01-30 18:20:40 +01:00
void WebContentClient::die()
{
Everywhere: Rename ASSERT => VERIFY (...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED) Since all of these checks are done in release builds as well, let's rename them to VERIFY to prevent confusion, as everyone is used to assertions being compiled out in release. We can introduce a new ASSERT macro that is specifically for debug checks, but I'm doing this wholesale conversion first since we've accumulated thousands of these already, and it's not immediately obvious which ones are suitable for ASSERT.
2021-02-23 20:42:32 +01:00
VERIFY(on_web_content_process_crash);
LibWeb: Handle WebContent process crashes gracefully :^) The OOPWV will now detect WebContent process crashes/disconnections and simply create a new WebContent process in its place. We also generate a little error page with a link to the crashing URL so you can reload and try again. This a huge step forward for OOPWV since it now has a feature that IPWV can never replicate. :^)
2021-01-30 18:20:40 +01:00
on_web_content_process_crash();
}
Ladybird+LibWebView: Remember the size of the last paint This will allow us to change the size of the backing store bitmap without conflating the size of the bitmap and the size of the paint.
2023-05-14 18:53:29 +02:00
void WebContentClient::did_paint(Gfx::IntRect const& rect, i32 bitmap_id)
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
{
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
m_view.server_did_paint({}, bitmap_id, rect.size());
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
}
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 WebContentClient::did_start_loading(AK::URL const& url, bool is_redirect)
{
m_view.set_url({}, url);
if (m_view.on_load_start)
m_view.on_load_start(url, is_redirect);
}
LibWeb: Add the Web::URL namespace and move URLEncoder to it This namespace will be used for all interfaces defined in the URL specification, like URL and URLSearchParams. This has the unfortunate side-effect of requiring us to use the fully qualified AK::URL name whenever we want to refer to the AK class, so this commit also fixes all such references.
2021-09-13 00:33:23 +03:00
void WebContentClient::did_finish_loading(AK::URL const& url)
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
{
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
m_view.set_url({}, url);
if (m_view.on_load_finish)
m_view.on_load_finish(url);
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
}
WebContent: Allow the WebContent process to trigger repaints After layout, we may want to repaint the page, so we now listen for the PageClient::page_did_invalidate() notification and use it to drive a client-side repaint. Note that an invalidation request from LibWeb makes a full roundtrip to the WebContent client and back since the client drives painting.
2020-06-17 18:00:18 +02:00
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
void WebContentClient::did_finish_text_test()
{
if (m_view.on_text_test_finish)
m_view.on_text_test_finish();
}
LibWebView+WebContent: Add IPCs to navigate the browser's history
2022-11-11 13:33:11 -05:00
void WebContentClient::did_request_navigate_back()
{
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
if (m_view.on_navigate_back)
m_view.on_navigate_back();
LibWebView+WebContent: Add IPCs to navigate the browser's history
2022-11-11 13:33:11 -05:00
}
void WebContentClient::did_request_navigate_forward()
{
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
if (m_view.on_navigate_forward)
m_view.on_navigate_forward();
LibWebView+WebContent: Add IPCs to navigate the browser's history
2022-11-11 13:33:11 -05:00
}
void WebContentClient::did_request_refresh()
{
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
if (m_view.on_refresh)
m_view.on_refresh();
LibWebView+WebContent: Add IPCs to navigate the browser's history
2022-11-11 13:33:11 -05:00
}
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
void WebContentClient::did_invalidate_content_rect(Gfx::IntRect const& content_rect)
WebContent: Allow the WebContent process to trigger repaints After layout, we may want to repaint the page, so we now listen for the PageClient::page_did_invalidate() notification and use it to drive a client-side repaint. Note that an invalidation request from LibWeb makes a full roundtrip to the WebContent client and back since the client drives painting.
2020-06-17 18:00:18 +02:00
{
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
dbgln_if(SPAM_DEBUG, "handle: WebContentClient::DidInvalidateContentRect! content_rect={}", content_rect);
WebContent: Allow the WebContent process to trigger repaints After layout, we may want to repaint the page, so we now listen for the PageClient::page_did_invalidate() notification and use it to drive a client-side repaint. Note that an invalidation request from LibWeb makes a full roundtrip to the WebContent client and back since the client drives painting.
2020-06-17 18:00:18 +02:00
// FIXME: Figure out a way to coalesce these messages to reduce unnecessary painting
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
m_view.server_did_invalidate_content_rect({}, content_rect);
WebContent: Allow the WebContent process to trigger repaints After layout, we may want to repaint the page, so we now listen for the PageClient::page_did_invalidate() notification and use it to drive a client-side repaint. Note that an invalidation request from LibWeb makes a full roundtrip to the WebContent client and back since the client drives painting.
2020-06-17 18:00:18 +02:00
}
WebContent: Notify client when web content selection changes The WebContentView widgets reacts to this by requesting a repaint.
2020-07-04 20:57:57 +02:00
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
void WebContentClient::did_change_selection()
WebContent: Notify client when web content selection changes The WebContentView widgets reacts to this by requesting a repaint.
2020-07-04 20:57:57 +02:00
{
Everywhere: Turn #if *_DEBUG into dbgln_if/if constexpr
2021-05-01 21:10:08 +02:00
dbgln_if(SPAM_DEBUG, "handle: WebContentClient::DidChangeSelection!");
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
m_view.server_did_change_selection({});
WebContent: Notify client when web content selection changes The WebContentView widgets reacts to this by requesting a repaint.
2020-07-04 20:57:57 +02:00
}
WebContent: Basic scrolling support! :^) The WebContentView widget now inherits from GUI::ScrollableWidget and will pass its scroll offset over to the WebContent process as it's changing. This is not super efficient and can get a bit laggy, but it will do fine as an initial scrolling implementation. Just like the single-process Web::PageView widget, WebContentView also paints scrolled content by translating the Gfx::Painter.
2020-07-04 23:19:32 +02:00
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
void WebContentClient::did_request_cursor_change(i32 cursor_type)
LibWeb: Support setting the cursor in OutOfProcessWebView
2021-02-27 21:12:12 +00:00
{
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
if (cursor_type < 0 || cursor_type >= (i32)Gfx::StandardCursor::__Count) {
LibWeb: Support setting the cursor in OutOfProcessWebView
2021-02-27 21:12:12 +00:00
dbgln("DidRequestCursorChange: Bad cursor type");
return;
}
Ladybird+LibWebView: Migrate cursor changes to LibWebView callbacks
2023-08-23 10:43:27 -04:00
if (m_view.on_cursor_change)
m_view.on_cursor_change(static_cast<Gfx::StandardCursor>(cursor_type));
LibWeb: Support setting the cursor in OutOfProcessWebView
2021-02-27 21:12:12 +00:00
}
Meta+Userland: Pass Gfx::IntSize by value Just two ints like Gfx::IntPoint.
2022-12-06 21:35:32 +00:00
void WebContentClient::did_layout(Gfx::IntSize content_size)
WebContent: Basic scrolling support! :^) The WebContentView widget now inherits from GUI::ScrollableWidget and will pass its scroll offset over to the WebContent process as it's changing. This is not super efficient and can get a bit laggy, but it will do fine as an initial scrolling implementation. Just like the single-process Web::PageView widget, WebContentView also paints scrolled content by translating the Gfx::Painter.
2020-07-04 23:19:32 +02:00
{
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
dbgln_if(SPAM_DEBUG, "handle: WebContentClient::DidLayout! content_size={}", content_size);
Ladybird+LibWebView: Migrate layout notification to LibWebView callbacks
2023-08-23 10:33:26 -04:00
if (m_view.on_did_layout)
m_view.on_did_layout(content_size);
WebContent: Basic scrolling support! :^) The WebContentView widget now inherits from GUI::ScrollableWidget and will pass its scroll offset over to the WebContent process as it's changing. This is not super efficient and can get a bit laggy, but it will do fine as an initial scrolling implementation. Just like the single-process Web::PageView widget, WebContentView also paints scrolled content by translating the Gfx::Painter.
2020-07-04 23:19:32 +02:00
}
WebContent: Plumb title changes over to the WebContentView WebContentView now fires its on_title_change hook, like Web::PageView. We use this in the WebView test app to update the window title. :^)
2020-07-04 23:40:17 +02:00
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
void WebContentClient::did_change_title(DeprecatedString const& title)
WebContent: Plumb title changes over to the WebContentView WebContentView now fires its on_title_change hook, like Web::PageView. We use this in the WebView test app to update the window title. :^)
2020-07-04 23:40:17 +02:00
{
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
dbgln_if(SPAM_DEBUG, "handle: WebContentClient::DidChangeTitle! title={}", title);
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
Browser+Ladybird+LibWebView: Consolidate title handling in LibWebView Namely, let's have empty titles behave the same in both Browser and Ladybird (display the URL).
2023-06-07 16:37:30 -04:00
if (!m_view.on_title_change)
return;
if (title.is_empty())
m_view.on_title_change(m_view.url().to_deprecated_string());
else
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
m_view.on_title_change(title);
WebContent: Plumb title changes over to the WebContentView WebContentView now fires its on_title_change hook, like Web::PageView. We use this in the WebView test app to update the window title. :^)
2020-07-04 23:40:17 +02:00
}
WebContent: Plumb scroll-into-view requests from server to client The WebContentView widget will now be able to react to scroll-into-view requests from the WebContent process.
2020-07-05 15:43:43 +02:00
LibWeb+WebContent: Modify did_request_scroll() IPC to take x&y deltas This is in preparation for implementing JS scrolling functions, which specify both x and y scrolling deltas. The visible behavior has not changed. Also, moved the "mouse wheel delta * 20" calculation to the `EventHandler` since the JS calls will want to work directly in pixels.
2021-09-08 11:22:44 +01:00
void WebContentClient::did_request_scroll(i32 x_delta, i32 y_delta)
LibWeb: Handle scrolling an OutOfProcessWebView When a mousewheel scroll event isn't handled by the web content itself (e.g. an overflowed box or similar), the event needs to get passed back up to the OutOfProcessWebView.
2021-03-02 08:39:07 +11:00
{
Ladybird+LibWebView: Migrate scrolling changes to LibWebView callbacks
2023-08-23 10:57:09 -04:00
if (m_view.on_scroll_by_delta)
m_view.on_scroll_by_delta(x_delta, y_delta);
LibWeb: Handle scrolling an OutOfProcessWebView When a mousewheel scroll event isn't handled by the web content itself (e.g. an overflowed box or similar), the event needs to get passed back up to the OutOfProcessWebView.
2021-03-02 08:39:07 +11:00
}
Meta+Userland: Pass Gfx::IntPoint by value This is just two ints or 8 bytes or the size of the reference on x86_64 or AArch64.
2022-12-06 20:27:44 +00:00
void WebContentClient::did_request_scroll_to(Gfx::IntPoint scroll_position)
LibWeb+WebContent: Add WebContentClient::did_request_scroll_to() call This call sets the absolute scroll position for the window.
2021-09-08 11:44:36 +01:00
{
Ladybird+LibWebView: Migrate scrolling changes to LibWebView callbacks
2023-08-23 10:57:09 -04:00
if (m_view.on_scroll_to_point)
m_view.on_scroll_to_point(scroll_position);
LibWeb+WebContent: Add WebContentClient::did_request_scroll_to() call This call sets the absolute scroll position for the window.
2021-09-08 11:44:36 +01:00
}
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
void WebContentClient::did_request_scroll_into_view(Gfx::IntRect const& rect)
WebContent: Plumb scroll-into-view requests from server to client The WebContentView widget will now be able to react to scroll-into-view requests from the WebContent process.
2020-07-05 15:43:43 +02:00
{
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
dbgln_if(SPAM_DEBUG, "handle: WebContentClient::DidRequestScrollIntoView! rect={}", rect);
Ladybird+LibWebView: Migrate scrolling changes to LibWebView callbacks
2023-08-23 10:57:09 -04:00
if (m_view.on_scroll_into_view)
m_view.on_scroll_into_view(rect);
WebContent: Plumb scroll-into-view requests from server to client The WebContentView widget will now be able to react to scroll-into-view requests from the WebContent process.
2020-07-05 15:43:43 +02:00
}
WebContent: Plumb hovered links from WebContent process over to widget Also add a little GUI::StatusBar to the demo app so we can see the hovered link URL's live. :^)
2020-07-05 16:59:20 +02:00
Meta+Userland: Pass Gfx::IntPoint by value This is just two ints or 8 bytes or the size of the reference on x86_64 or AArch64.
2022-12-06 20:27:44 +00:00
void WebContentClient::did_enter_tooltip_area(Gfx::IntPoint content_position, DeprecatedString const& title)
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 12:10:06 -04:00
{
Ladybird+LibWebView: Migrate tooltip changes to LibWebView callbacks
2023-08-23 11:11:39 -04:00
if (m_view.on_enter_tooltip_area)
m_view.on_enter_tooltip_area(m_view.to_widget_position(content_position), title);
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 12:10:06 -04:00
}
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
void WebContentClient::did_leave_tooltip_area()
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 12:10:06 -04:00
{
Ladybird+LibWebView: Migrate tooltip changes to LibWebView callbacks
2023-08-23 11:11:39 -04:00
if (m_view.on_leave_tooltip_area)
m_view.on_leave_tooltip_area();
LibWeb+WebContent: Support displaying tooltips in OOPWV
2021-03-30 12:10:06 -04:00
}
LibWeb: Add the Web::URL namespace and move URLEncoder to it This namespace will be used for all interfaces defined in the URL specification, like URL and URLSearchParams. This has the unfortunate side-effect of requiring us to use the fully qualified AK::URL name whenever we want to refer to the AK class, so this commit also fixes all such references.
2021-09-13 00:33:23 +03:00
void WebContentClient::did_hover_link(AK::URL const& url)
WebContent: Plumb hovered links from WebContent process over to widget Also add a little GUI::StatusBar to the demo app so we can see the hovered link URL's live. :^)
2020-07-05 16:59:20 +02:00
{
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
dbgln_if(SPAM_DEBUG, "handle: WebContentClient::DidHoverLink! url={}", url);
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
if (m_view.on_link_hover)
m_view.on_link_hover(url);
WebContent: Plumb hovered links from WebContent process over to widget Also add a little GUI::StatusBar to the demo app so we can see the hovered link URL's live. :^)
2020-07-05 16:59:20 +02:00
}
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
void WebContentClient::did_unhover_link()
WebContent: Plumb hovered links from WebContent process over to widget Also add a little GUI::StatusBar to the demo app so we can see the hovered link URL's live. :^)
2020-07-05 16:59:20 +02:00
{
Everywhere: Turn #if *_DEBUG into dbgln_if/if constexpr
2021-05-01 21:10:08 +02:00
dbgln_if(SPAM_DEBUG, "handle: WebContentClient::DidUnhoverLink!");
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
if (m_view.on_link_unhover)
m_view.on_link_unhover();
WebContent: Plumb hovered links from WebContent process over to widget Also add a little GUI::StatusBar to the demo app so we can see the hovered link URL's live. :^)
2020-07-05 16:59:20 +02:00
}
WebContent: Plumb link clicks to the WebContentView :^) You can now react to links being clicked via the on_link_click hook.
2020-07-06 20:01:46 +02:00
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
void WebContentClient::did_click_link(AK::URL const& url, DeprecatedString const& target, unsigned modifiers)
WebContent: Plumb link clicks to the WebContentView :^) You can now react to links being clicked via the on_link_click hook.
2020-07-06 20:01:46 +02: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
if (m_view.on_link_click)
m_view.on_link_click(url, target, modifiers);
WebContent: Plumb link clicks to the WebContentView :^) You can now react to links being clicked via the on_link_click hook.
2020-07-06 20:01:46 +02:00
}
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
void WebContentClient::did_middle_click_link(AK::URL const& url, DeprecatedString const& target, unsigned modifiers)
WebContent: Plumb link clicks to the WebContentView :^) You can now react to links being clicked via the on_link_click hook.
2020-07-06 20:01:46 +02: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
if (m_view.on_link_middle_click)
m_view.on_link_middle_click(url, target, modifiers);
LibWeb: Make the WebContentView::on_load_start hook actually work :^)
2020-07-06 21:58:16 +02:00
}
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 12:24:29 +02:00
Meta+Userland: Pass Gfx::IntPoint by value This is just two ints or 8 bytes or the size of the reference on x86_64 or AArch64.
2022-12-06 20:27:44 +00:00
void WebContentClient::did_request_context_menu(Gfx::IntPoint content_position)
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 12:24:29 +02: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
if (m_view.on_context_menu_request)
m_view.on_context_menu_request(m_view.to_widget_position(content_position));
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 12:24:29 +02: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 WebContentClient::did_request_link_context_menu(Gfx::IntPoint content_position, AK::URL const& url, DeprecatedString const&, unsigned)
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 12:24:29 +02: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
if (m_view.on_link_context_menu_request)
m_view.on_link_context_menu_request(url, m_view.to_widget_position(content_position));
LibWeb: Make context menus work in WebContentView As usual, this was just a matter of plumbing the PageClient calls from the WebContent side over to the WebContentView side. :^)
2020-07-07 12:24:29 +02:00
}
LibWeb: Move OutOfProcessWebView into the Web namespace
2020-08-24 15:33:18 +04:30
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 WebContentClient::did_request_image_context_menu(Gfx::IntPoint content_position, AK::URL const& url, DeprecatedString const&, unsigned, Gfx::ShareableBitmap const& bitmap)
LibWeb+WebContent: Support image context menus in OOPWV You can now right-click images in web content and get a context menu.
2021-04-11 16:49:25 +02: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
if (m_view.on_image_context_menu_request)
m_view.on_image_context_menu_request(url, m_view.to_widget_position(content_position), bitmap);
LibWeb+WebContent: Support image context menus in OOPWV You can now right-click images in web content and get a context menu.
2021-04-11 16:49:25 +02: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 WebContentClient::did_request_media_context_menu(Gfx::IntPoint content_position, DeprecatedString const&, unsigned, Web::Page::MediaContextMenu const& menu)
Browser+LibWeb+WebContent: Broadcast video element context menu requests This just sets up the IPC to notify the browser process of context menu requests on video elements. The IPC contains a few pieces of information about the state of the video element.
2023-05-15 09:42:56 -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
if (m_view.on_media_context_menu_request)
m_view.on_media_context_menu_request(m_view.to_widget_position(content_position), menu);
Browser+LibWeb+WebContent: Broadcast video element context menu requests This just sets up the IPC to notify the browser process of context menu requests on video elements. The IPC contains a few pieces of information about the state of the video element.
2023-05-15 09:42:56 -04:00
}
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
void WebContentClient::did_get_source(AK::URL const& url, DeprecatedString const& source)
LibWeb: Added get source functionality and hook event
2021-02-23 06:17:23 -06:00
{
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
if (m_view.on_received_source)
m_view.on_received_source(url, source);
LibWeb: Added get source functionality and hook event
2021-02-23 06:17:23 -06:00
}
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
void WebContentClient::did_get_dom_tree(DeprecatedString const& dom_tree)
LibWeb+WebContent: Add IPC flow for Inspect DOM Tree Add `inspect_dom_tree` to WebContentServer and 'did_get_dom_tree' to WebContentClient. These two async methods form a request & response for requesting a JSON representation of the Content's DOM tree.
2021-06-07 16:35:10 +01:00
{
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
if (m_view.on_received_dom_tree)
m_view.on_received_dom_tree(dom_tree);
LibWeb+WebContent: Add IPC flow for Inspect DOM Tree Add `inspect_dom_tree` to WebContentServer and 'did_get_dom_tree' to WebContentClient. These two async methods form a request & response for requesting a JSON representation of the Content's DOM tree.
2021-06-07 16:35:10 +01:00
}
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
void WebContentClient::did_get_dom_node_properties(i32 node_id, DeprecatedString const& computed_style, DeprecatedString const& resolved_style, DeprecatedString const& custom_properties, DeprecatedString const& node_box_sizing, DeprecatedString const& aria_properties_state)
LibWeb+WebContent: Implement asynchronous DOM Node properties call This lets us "push" a new style-properties list to the DOM Inspector, for example when JS changes the style of the inspected node.
2021-08-27 12:47:30 +01:00
{
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
if (m_view.on_received_dom_node_properties)
m_view.on_received_dom_node_properties(node_id, computed_style, resolved_style, custom_properties, node_box_sizing, aria_properties_state);
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 WebContentClient::did_get_accessibility_tree(DeprecatedString const& 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
if (m_view.on_received_accessibility_tree)
m_view.on_received_accessibility_tree(accessibility_tree);
LibWeb+WebContent: Implement asynchronous DOM Node properties call This lets us "push" a new style-properties list to the DOM Inspector, for example when JS changes the style of the inspected node.
2021-08-27 12:47:30 +01:00
}
LibWeb+WebContent: Add new console-message IPC calls This patch introduces three new IPC calls for WebContent: - `Client::did_output_js_console_message(index)`: Notifies the client that a new console message was logged. - `Server::js_console_request_messages(start_index)`: Ask the server for console messages starting at the given index. - `Client::did_get_js_console_messages(start_index, types, messages)`: Send the client the messages they requested. This mechanism will replace the current `Client::did_js_console_output()` call in the next few commits. This will allow us to display messages in the console that happened before the console was opened.
2021-09-04 11:14:25 +01:00
void WebContentClient::did_output_js_console_message(i32 message_index)
{
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
if (m_view.on_received_console_message)
m_view.on_received_console_message(message_index);
LibWeb+WebContent: Add new console-message IPC calls This patch introduces three new IPC calls for WebContent: - `Client::did_output_js_console_message(index)`: Notifies the client that a new console message was logged. - `Server::js_console_request_messages(start_index)`: Ask the server for console messages starting at the given index. - `Client::did_get_js_console_messages(start_index, types, messages)`: Send the client the messages they requested. This mechanism will replace the current `Client::did_js_console_output()` call in the next few commits. This will allow us to display messages in the console that happened before the console was opened.
2021-09-04 11:14:25 +01:00
}
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
void WebContentClient::did_get_js_console_messages(i32 start_index, Vector<DeprecatedString> const& message_types, Vector<DeprecatedString> const& messages)
LibWeb+WebContent: Add new console-message IPC calls This patch introduces three new IPC calls for WebContent: - `Client::did_output_js_console_message(index)`: Notifies the client that a new console message was logged. - `Server::js_console_request_messages(start_index)`: Ask the server for console messages starting at the given index. - `Client::did_get_js_console_messages(start_index, types, messages)`: Send the client the messages they requested. This mechanism will replace the current `Client::did_js_console_output()` call in the next few commits. This will allow us to display messages in the console that happened before the console was opened.
2021-09-04 11:14:25 +01:00
{
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
if (m_view.on_received_console_messages)
m_view.on_received_console_messages(start_index, message_types, messages);
LibWeb+WebContent: Add new console-message IPC calls This patch introduces three new IPC calls for WebContent: - `Client::did_output_js_console_message(index)`: Notifies the client that a new console message was logged. - `Server::js_console_request_messages(start_index)`: Ask the server for console messages starting at the given index. - `Client::did_get_js_console_messages(start_index, types, messages)`: Send the client the messages they requested. This mechanism will replace the current `Client::did_js_console_output()` call in the next few commits. This will allow us to display messages in the console that happened before the console was opened.
2021-09-04 11:14:25 +01:00
}
LibWeb+Ladybird+Userland: Port window.[alert,confirm,prompt] to String LibGUI and WebDriver (read: JSON) API boundaries use DeprecatedString, so that is as far as these changes can reach. The one change which isn't just a DeprecatedString to String replacement is handling the "null" prompt response. We previously checked for the null DeprecatedString, whereas we now represent this as an empty Optional<String>.
2023-03-13 17:30:51 -04:00
void WebContentClient::did_request_alert(String const& message)
LibWeb: Support window.alert() in multi-process context Alerts are now delegated to the embedding GUI process.
2020-09-12 11:56:13 +02:00
{
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
if (m_view.on_request_alert)
m_view.on_request_alert(message);
LibWeb: Support window.alert() in multi-process context Alerts are now delegated to the embedding GUI process.
2020-09-12 11:56:13 +02:00
}
LibWeb+Ladybird+Userland: Port window.[alert,confirm,prompt] to String LibGUI and WebDriver (read: JSON) API boundaries use DeprecatedString, so that is as far as these changes can reach. The one change which isn't just a DeprecatedString to String replacement is handling the "null" prompt response. We previously checked for the null DeprecatedString, whereas we now represent this as an empty Optional<String>.
2023-03-13 17:30:51 -04:00
void WebContentClient::did_request_confirm(String const& message)
LibWeb+WebContent: Support window.confirm() in OOPWV
2021-02-10 08:48:28 +01:00
{
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
if (m_view.on_request_confirm)
m_view.on_request_confirm(message);
LibWeb+WebContent: Support window.confirm() in OOPWV
2021-02-10 08:48:28 +01:00
}
LibWeb+Ladybird+Userland: Port window.[alert,confirm,prompt] to String LibGUI and WebDriver (read: JSON) API boundaries use DeprecatedString, so that is as far as these changes can reach. The one change which isn't just a DeprecatedString to String replacement is handling the "null" prompt response. We previously checked for the null DeprecatedString, whereas we now represent this as an empty Optional<String>.
2023-03-13 17:30:51 -04:00
void WebContentClient::did_request_prompt(String const& message, String const& default_)
LibWeb: Implement Window.prompt()
2021-02-20 12:05:18 +01:00
{
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
if (m_view.on_request_prompt)
m_view.on_request_prompt(message, default_);
LibWeb: Implement Window.prompt()
2021-02-20 12:05:18 +01:00
}
LibWeb+Ladybird+Userland: Port window.[alert,confirm,prompt] to String LibGUI and WebDriver (read: JSON) API boundaries use DeprecatedString, so that is as far as these changes can reach. The one change which isn't just a DeprecatedString to String replacement is handling the "null" prompt response. We previously checked for the null DeprecatedString, whereas we now represent this as an empty Optional<String>.
2023-03-13 17:30:51 -04:00
void WebContentClient::did_request_set_prompt_text(String const& message)
LibWeb+LibWebView+WebContent+WebDriver: Implement Send Alert Text
2022-11-16 08:57:05 -05:00
{
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
if (m_view.on_request_set_prompt_text)
m_view.on_request_set_prompt_text(message);
LibWeb+LibWebView+WebContent+WebDriver: Implement Send Alert Text
2022-11-16 08:57:05 -05:00
}
LibWebView+WebContent: Begin handling open user dialogs for WebDriver The way in which dialogs should be handled is configurable by the driver capabilities object, which we don't support yet. So this implements just the default mode to dismiss the dialog and return an error if there is one open. In the OOPWV, this means we need to refer to the dialog after it has been open, so we now hold a pointer to whatever dialog is open.
2022-11-16 06:58:14 -05:00
void WebContentClient::did_request_accept_dialog()
{
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
if (m_view.on_request_accept_dialog)
m_view.on_request_accept_dialog();
LibWebView+WebContent: Begin handling open user dialogs for WebDriver The way in which dialogs should be handled is configurable by the driver capabilities object, which we don't support yet. So this implements just the default mode to dismiss the dialog and return an error if there is one open. In the OOPWV, this means we need to refer to the dialog after it has been open, so we now hold a pointer to whatever dialog is open.
2022-11-16 06:58:14 -05:00
}
void WebContentClient::did_request_dismiss_dialog()
{
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
if (m_view.on_request_dismiss_dialog)
m_view.on_request_dismiss_dialog();
LibWebView+WebContent: Begin handling open user dialogs for WebDriver The way in which dialogs should be handled is configurable by the driver capabilities object, which we don't support yet. So this implements just the default mode to dismiss the dialog and return an error if there is one open. In the OOPWV, this means we need to refer to the dialog after it has been open, so we now hold a pointer to whatever dialog is open.
2022-11-16 06:58:14 -05:00
}
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
void WebContentClient::did_change_favicon(Gfx::ShareableBitmap const& favicon)
LibWeb+WebContent: Support displaying favicons in OOPWV In single process mode, the browser will display a page's favicon in both the location bar and tab. This adds the same support for multi- process mode.
2021-03-26 10:41:25 -04:00
{
Userland: Change IPC funcs to use plain arguments instead of a struct Instead of having a single overloaded handle method each method gets its own unique method name now.
2021-05-02 19:54:34 +02:00
if (!favicon.is_valid()) {
LibWeb+WebContent: Support displaying favicons in OOPWV In single process mode, the browser will display a page's favicon in both the location bar and tab. This adds the same support for multi- process mode.
2021-03-26 10:41:25 -04:00
dbgln("DidChangeFavicon: Received invalid favicon");
return;
}
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
if (m_view.on_favicon_change)
m_view.on_favicon_change(*favicon.bitmap());
LibWeb+WebContent: Support displaying favicons in OOPWV In single process mode, the browser will display a page's favicon in both the location bar and tab. This adds the same support for multi- process mode.
2021-03-26 10:41:25 -04:00
}
LibWebView+WebContent: Add IPC to get all cookies for a document's URL
2022-11-11 09:23:24 -05:00
Messages::WebContentClient::DidRequestAllCookiesResponse WebContentClient::did_request_all_cookies(AK::URL const& url)
{
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
if (m_view.on_get_all_cookies)
return m_view.on_get_all_cookies(url);
return Vector<Web::Cookie::Cookie> {};
LibWebView+WebContent: Add IPC to get all cookies for a document's URL
2022-11-11 09:23:24 -05:00
}
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
Messages::WebContentClient::DidRequestNamedCookieResponse WebContentClient::did_request_named_cookie(AK::URL const& url, DeprecatedString const& name)
LibWebView+WebContent: Add IPC to get a document's named cookie
2022-11-11 09:46:56 -05: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
if (m_view.on_get_named_cookie)
return m_view.on_get_named_cookie(url, name);
return OptionalNone {};
LibWebView+WebContent: Add IPC to get a document's named cookie
2022-11-11 09:46:56 -05:00
}
LibWeb: Add the Web::URL namespace and move URLEncoder to it This namespace will be used for all interfaces defined in the URL specification, like URL and URLSearchParams. This has the unfortunate side-effect of requiring us to use the fully qualified AK::URL name whenever we want to refer to the AK class, so this commit also fixes all such references.
2021-09-13 00:33:23 +03:00
Messages::WebContentClient::DidRequestCookieResponse WebContentClient::did_request_cookie(AK::URL const& url, u8 source)
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 10:54:11 -04: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
if (m_view.on_get_cookie)
return m_view.on_get_cookie(url, static_cast<Web::Cookie::Source>(source));
return DeprecatedString {};
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 10:54:11 -04:00
}
LibWeb: Add the Web::URL namespace and move URLEncoder to it This namespace will be used for all interfaces defined in the URL specification, like URL and URLSearchParams. This has the unfortunate side-effect of requiring us to use the fully qualified AK::URL name whenever we want to refer to the AK class, so this commit also fixes all such references.
2021-09-13 00:33:23 +03:00
void WebContentClient::did_set_cookie(AK::URL const& url, Web::Cookie::ParsedCookie const& cookie, u8 source)
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 10:54:11 -04: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
if (m_view.on_set_cookie)
m_view.on_set_cookie(url, cookie, static_cast<Web::Cookie::Source>(source));
LibWeb+WebContent: Hook document.cookie to the backend cookie storage
2021-04-11 10:54:11 -04:00
}
Browser+LibWebView+WebContent: Do not domain match on cookie updates Updating cookies through these hooks happens in one of two manners: 1. Through the Browser's storage inspector. 2. Through WebDriver's delete-cookies operation. In (1), we should not restrict ourselves to being able to delete cookies for the current page. For example, it's handy to open the inspector from the welcome page and be able to delete cookies for any domain. In (2), we already are only interacting with cookies that have been matched against the document URL.
2022-11-28 11:24:04 -05:00
void WebContentClient::did_update_cookie(Web::Cookie::Cookie const& cookie)
LibWebView+WebContent: Add IPC to update a document's cookie
2022-11-11 11:18:40 -05: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
if (m_view.on_update_cookie)
m_view.on_update_cookie(cookie);
LibWebView+WebContent: Add IPC to update a document's cookie
2022-11-11 11:18:40 -05:00
}
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
Messages::WebContentClient::DidRequestNewTabResponse WebContentClient::did_request_new_tab(Web::HTML::ActivateTab const& activate_tab)
LibWeb+LibWebView+WebContent+Ladybird: Add IPC call that opens new tab
2023-03-14 17:12:09 +03: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
if (m_view.on_new_tab)
return m_view.on_new_tab(activate_tab);
return String {};
LibWeb+LibWebView+WebContent+Ladybird: Add IPC call that opens new tab
2023-03-14 17:12:09 +03:00
}
WebContent+Everywhere: Add a WebContent IPC to activate a tab
2023-03-20 19:52:00 -04:00
void WebContentClient::did_request_activate_tab()
{
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
if (m_view.on_activate_tab)
m_view.on_activate_tab();
WebContent+Everywhere: Add a WebContent IPC to activate a tab
2023-03-20 19:52:00 -04:00
}
LibWebView+WebContent: Propagate close from WebContent to LibWebView
2023-03-07 06:10:26 +03:00
void WebContentClient::did_close_browsing_context()
{
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
if (m_view.on_close)
m_view.on_close();
LibWebView+WebContent: Propagate close from WebContent to LibWebView
2023-03-07 06:10:26 +03:00
}
Browser: Show currently loading host and remaining resource count
2022-02-20 17:03:39 -05:00
void WebContentClient::did_update_resource_count(i32 count_waiting)
{
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
if (m_view.on_resource_status_change)
m_view.on_resource_status_change(count_waiting);
Browser: Show currently loading host and remaining resource count
2022-02-20 17:03:39 -05:00
}
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 09:51:39 -05:00
void WebContentClient::did_request_restore_window()
{
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
if (m_view.on_restore_window)
m_view.on_restore_window();
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 09:51:39 -05:00
}
Meta+Userland: Pass Gfx::IntPoint by value This is just two ints or 8 bytes or the size of the reference on x86_64 or AArch64.
2022-12-06 20:27:44 +00:00
Messages::WebContentClient::DidRequestRepositionWindowResponse WebContentClient::did_request_reposition_window(Gfx::IntPoint position)
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 09:51:39 -05: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
if (m_view.on_reposition_window)
return m_view.on_reposition_window(position);
return Gfx::IntPoint {};
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 09:51:39 -05:00
}
Meta+Userland: Pass Gfx::IntSize by value Just two ints like Gfx::IntPoint.
2022-12-06 21:35:32 +00:00
Messages::WebContentClient::DidRequestResizeWindowResponse WebContentClient::did_request_resize_window(Gfx::IntSize size)
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 09:51:39 -05: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
if (m_view.on_resize_window)
return m_view.on_resize_window(size);
return Gfx::IntSize {};
Browser+LibWebView+WebContent: Add IPC to re[store,size,position] window Requests to restore, resize, and reposition Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser. The spec notes "The specification does not guarantee that the resulting window size will exactly match that which was requested", so these new methods return the actual new size/position.
2022-11-09 09:51:39 -05:00
}
Browser+LibWebView+WebContent: Add IPC to minimize and maximize window Requests to maximize and minimize Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser.
2022-11-09 10:04:09 -05:00
Messages::WebContentClient::DidRequestMaximizeWindowResponse WebContentClient::did_request_maximize_window()
{
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
if (m_view.on_maximize_window)
return m_view.on_maximize_window();
return Gfx::IntRect {};
Browser+LibWebView+WebContent: Add IPC to minimize and maximize window Requests to maximize and minimize Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser.
2022-11-09 10:04:09 -05:00
}
Messages::WebContentClient::DidRequestMinimizeWindowResponse WebContentClient::did_request_minimize_window()
{
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
if (m_view.on_minimize_window)
return m_view.on_minimize_window();
return Gfx::IntRect {};
Browser+LibWebView+WebContent: Add IPC to minimize and maximize window Requests to maximize and minimize Browser windows will be coming from the WebContent process rather than the WebDriver process. Add hooks to propagate these requests back up to the Browser.
2022-11-09 10:04:09 -05:00
}
WebDriver: Implement `POST /session/{id}/window/fullscreen` endpoint
2022-11-09 19:09:17 +01:00
Messages::WebContentClient::DidRequestFullscreenWindowResponse WebContentClient::did_request_fullscreen_window()
{
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
if (m_view.on_fullscreen_window)
return m_view.on_fullscreen_window();
return Gfx::IntRect {};
WebDriver: Implement `POST /session/{id}/window/fullscreen` endpoint
2022-11-09 19:09:17 +01:00
}
AK+Everywhere: Rename String to DeprecatedString We have a new, improved string type coming up in AK (OOM aware, no null state), and while it's going to use UTF-8, the name UTF8String is a mouthful - so let's free up the String name by renaming the existing class. Making the old one have an annoying name will hopefully also help with quick adoption :^)
2022-12-04 18:02:33 +00:00
void WebContentClient::did_request_file(DeprecatedString const& path, i32 request_id)
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
{
Ladybird+LibWebView: Migrate file APIs to LibWebView callbacks This also sets the default callback to do what every non-Serenity browser is doing, rather than copy-pasting this callback into every implementation. The callback is still available for any platform which might want to override the default behavior. For example, OOPWV now overrides this callback to use FileSystemAccessClient.
2023-08-23 06:54:22 -04:00
if (m_view.on_request_file)
m_view.on_request_file(path, request_id);
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
}
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 WebContentClient::did_request_color_picker(Color const& current_color)
{
if (m_view.on_request_color_picker)
m_view.on_request_color_picker(current_color);
}
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
void WebContentClient::did_finish_handling_input_event(bool event_was_accepted)
{
Ladybird+LibWebView: Migrate input completions to LibWebView callbacks
2023-08-23 11:19:21 -04:00
if (m_view.on_finish_handling_input_event)
m_view.on_finish_handling_input_event(event_was_accepted);
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
}
LibWeb+LibWebView+WebContent: Add support for meta theme-color
2023-09-19 01:51:48 +02:00
void WebContentClient::did_change_theme_color(Gfx::Color color)
{
if (m_view.on_theme_color_change)
m_view.on_theme_color_change(color);
}
LibWeb: Move OutOfProcessWebView into the Web namespace
2020-08-24 15:33:18 +04:30
}
Reference in a new issue Copy permalink