Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-04 07:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWebView/ViewImplementation.cpp

1029 lines
37 KiB
C++
Raw Normal View History

LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
/*
* Copyright (c) 2023, Linus Groh <linusg@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
#include <AK/Error.h>
#include <AK/String.h>
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
#include <AK/TemporaryChange.h>
Everywhere: Replace DateTime::to_string() with UnixDateTime::to_string() Replace LibCore::DateTime::to_string() with AK::UnixDateTime::to_string(). Remove unncessary #include <LibCore/DateTime.h>.
2025-06-19 21:05:42 +02:00
#include <AK/Time.h>
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
#include <LibCore/StandardPaths.h>
LibIPC: Move stuff from Connection.h to .cpp and reduce #include count
2024-06-28 14:24:49 +02:00
#include <LibCore/Timer.h>
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
#include <LibGfx/ImageFormats/PNGWriter.h>
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
#include <LibURL/Parser.h>
LibWebView+UI: Handle common WebView client initialization in LibWebView No need to have every UI manually implement these common steps.
2024-11-13 16:35:17 -05:00
#include <LibWeb/Crypto/Crypto.h>
LibWebView: Add a helper to get selected text with collapsed whitespace
2023-10-23 16:52:57 -04:00
#include <LibWeb/Infra/Strings.h>
LibWebView: Use the download directory facility for saving files
2024-08-28 15:32:50 -04:00
#include <LibWebView/Application.h>
LibWebView+UI: Handle common WebView client initialization in LibWebView No need to have every UI manually implement these common steps.
2024-11-13 16:35:17 -05:00
#include <LibWebView/HelperProcess.h>
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
#include <LibWebView/Menu.h>
LibWeb+LibWebView+WebContent: Begin implementing simple site islotation Site isolation is a common technique to reduce the chance that malicious sites can access data from other sites. When the user navigates, we now check if the target site is the same as the current site. If not, we instruct the UI to perform the navigation in a new WebContent process. The phrase "site" here is defined as the public suffix of the URL plus one level. This means that navigating from "www.example.com" to "sub.example.com" remains in the same process. There's plenty of room for optimization around this. For example, we can create a spare WebContent process ahead of time to hot-swap the target site. We can also create a policy to keep the navigated-from process around, in case the user quickly navigates back.
2025-03-09 11:40:34 -04:00
#include <LibWebView/SiteIsolation.h>
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
#include <LibWebView/URL.h>
LibWebView+UI: Handle common WebView client initialization in LibWebView No need to have every UI manually implement these common steps.
2024-11-13 16:35:17 -05:00
#include <LibWebView/UserAgent.h>
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
#include <LibWebView/ViewImplementation.h>
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
#ifdef AK_OS_MACOS
# include <LibCore/IOSurface.h>
# include <LibCore/MachPort.h>
#endif
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
namespace WebView {
LibWebView: Add simple ID tracking to WebViews For Firefox DevTools, we will need to track WebViews by a numerical ID. Here, we just increment a static 64-bit counter. We can switch to using IDAllocator if we ever have an issue with this. This patch adds such an ID to the views and a couple of APIs to access WebViews after creation.
2025-02-15 08:06:36 -05:00
static HashMap<u64, ViewImplementation*> s_all_views;
static u64 s_view_count = 1; // This has to start at 1 for Firefox DevTools.
void ViewImplementation::for_each_view(Function<IterationDecision(ViewImplementation&)> callback)
{
for (auto& view : s_all_views) {
if (callback(*view.value) == IterationDecision::Break)
break;
}
}
Optional<ViewImplementation&> ViewImplementation::find_view_by_id(u64 id)
{
if (auto view = s_all_views.get(id); view.has_value())
return *view.value();
return {};
}
Ladybird+LibWebView+Browser: Remove ability to run with AST interpreter
2023-08-07 16:44:20 +02:00
ViewImplementation::ViewImplementation()
LibWebView: Add simple ID tracking to WebViews For Firefox DevTools, we will need to track WebViews by a numerical ID. Here, we just increment a static 64-bit counter. We can switch to using IDAllocator if we ever have an issue with this. This patch adds such an ID to the views and a couple of APIs to access WebViews after creation.
2025-02-15 08:06:36 -05:00
: m_view_id(s_view_count++)
Ladybird+LibWebView: Move backing store management code to LibWebView This lets us share this code on all platforms, and makes resizing the window much faster on SerenityOS as well. :^)
2023-05-15 07:59:51 +02:00
{
LibWebView: Add simple ID tracking to WebViews For Firefox DevTools, we will need to track WebViews by a numerical ID. Here, we just increment a static 64-bit counter. We can switch to using IDAllocator if we ever have an issue with this. This patch adds such an ID to the views and a couple of APIs to access WebViews after creation.
2025-02-15 08:06:36 -05:00
s_all_views.set(m_view_id, this);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
initialize_context_menus();
LibWebView: Don't re-create WebContent proceses when repeatedly crashing Serenity handles this in the SystemServer already, but the simplest place to put this logic is the ViewImplementation base class. This is trivial to see when running Ladybird without SERENTIY_SOURCE_DIR set, or set improperly.
2023-05-27 10:46:45 -06:00
m_repeated_crash_timer = Core::Timer::create_single_shot(1000, [this] {
// Reset the "crashing a lot" counter after 1 second in case we just
// happen to be visiting crashy websites a lot.
this->m_crash_count = 0;
LibCore: Stop obsessing about tiny OOMs in Core::Timer Work towards #20405
2024-04-16 20:34:01 +02: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
on_request_file = [this](auto const& path, auto request_id) {
auto file = Core::File::open(path, Core::File::OpenMode::Read);
if (file.is_error())
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_handle_file_return(page_id(), file.error().code(), {}, request_id);
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
else
LibIPC+Userland: Make IPC::File always own its file descriptor Add factory functions to distinguish between when the owner of the File wants to transfer ownership to the new IPC object (adopt) or to send a copy of the same fd to the IPC peer (clone). This behavior is more intuitive than the previous behavior. Previously, an IPC::File would default to a shallow clone of the file descriptor, only *actually* calling dup(2) for the fd when encoding or it into an IPC MessageBuffer. Now the dup(2) for the fd is explicit in the clone_fd factory function.
2024-04-16 13:46:30 -06:00
client().async_handle_file_return(page_id(), 0, IPC::File::adopt_file(file.release_value()), request_id);
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
};
Ladybird+LibWebView: Move backing store management code to LibWebView This lets us share this code on all platforms, and makes resizing the window much faster on SerenityOS as well. :^)
2023-05-15 07:59:51 +02:00
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
ViewImplementation::~ViewImplementation()
{
LibWebView: Add simple ID tracking to WebViews For Firefox DevTools, we will need to track WebViews by a numerical ID. Here, we just increment a static 64-bit counter. We can switch to using IDAllocator if we ever have an issue with this. This patch adds such an ID to the views and a couple of APIs to access WebViews after creation.
2025-02-15 08:06:36 -05:00
s_all_views.remove(m_view_id);
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
if (m_client_state.client)
m_client_state.client->unregister_view(m_client_state.page_index);
}
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
WebContentClient& ViewImplementation::client()
{
VERIFY(m_client_state.client);
return *m_client_state.client;
}
WebContentClient const& ViewImplementation::client() const
{
VERIFY(m_client_state.client);
return *m_client_state.client;
}
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
u64 ViewImplementation::page_id() const
{
VERIFY(m_client_state.client);
return m_client_state.page_index;
}
LibWeb+LibWebView+WebContent: Begin implementing simple site islotation Site isolation is a common technique to reduce the chance that malicious sites can access data from other sites. When the user navigates, we now check if the target site is the same as the current site. If not, we instruct the UI to perform the navigation in a new WebContent process. The phrase "site" here is defined as the public suffix of the URL plus one level. This means that navigating from "www.example.com" to "sub.example.com" remains in the same process. There's plenty of room for optimization around this. For example, we can create a spare WebContent process ahead of time to hot-swap the target site. We can also create a policy to keep the navigated-from process around, in case the user quickly navigates back.
2025-03-09 11:40:34 -04:00
void ViewImplementation::create_new_process_for_cross_site_navigation(URL::URL const& url)
{
if (m_client_state.client)
client().async_close_server();
initialize_client();
VERIFY(m_client_state.client);
// Don't keep a stale backup bitmap around.
m_backup_bitmap = nullptr;
handle_resize();
load(url);
}
Ladybird+LibWebView: Move most of paint handling to LibWebView Storing the backup bitmap is the same across Browser and Ladybird. Just peform that work in LibWebView, and handle only the implementation- specific nuances within the browsers.
2023-05-20 10:50:05 -04:00
void ViewImplementation::server_did_paint(Badge<WebContentClient>, i32 bitmap_id, Gfx::IntSize size)
{
LibWebView+WebContent: Drive repainting from WebContent process With this change, chrome no longer has to ask the WebContent process to paint the next frame into a specified bitmap. Instead, it allocates bitmaps and sends them to WebContent, which then lets chrome know when the painting is done. This work is a preparation to move the execution of painting commands into a separate thread. Now, it is much easier to start working on the next frame while the current one is still rendering. This is because WebContent does not have to inform chrome that the current frame is ready before it can request the next frame. Additionally, as a side bonus, we can now eliminate the did_invalidate_content_rect and did_change_selection IPC calls. These were used solely for the purpose of informing chrome that it needed to request a repaint.
2023-12-21 22:58:54 +01:00
if (m_client_state.back_bitmap.id == bitmap_id) {
m_client_state.has_usable_bitmap = true;
m_client_state.back_bitmap.last_painted_size = size.to_type<Web::DevicePixels>();
swap(m_client_state.back_bitmap, m_client_state.front_bitmap);
m_backup_bitmap = nullptr;
if (on_ready_to_paint)
on_ready_to_paint();
Ladybird+LibWebView: Move most of paint handling to LibWebView Storing the backup bitmap is the same across Browser and Ladybird. Just peform that work in LibWebView, and handle only the implementation- specific nuances within the browsers.
2023-05-20 10:50:05 -04:00
}
LibWebView+WebContent: Let the WebView client broadcast when it painted When the WebContent process has painted to its shared bitmaps, it sends a synchronous IPC to the browser process to let the chrome paint. It is synchronous to ensure the WC process doesn't paint onto the backing bitmap again while it is being displayed. However, this can cause a crash at exit if the browser process quits while the WC process is waiting for a response to this IPC. This patch makes the painting logic asynchronous by letting the browser process broadcast when it has finished handling the paint IPC. The WC process will not paint anything again until it receives that message. If it had tried to repaint while waiting for that message, that paint will be deferred until it arrives.
2024-01-07 10:35:45 -05:00
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_ready_to_paint(page_id());
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
}
UI/AppKit: Inform WebContent of the UI window position/size This is required for APIs like window.screenX, as well as for WebDriver and WPT.
2024-10-28 07:48:49 -04:00
void ViewImplementation::set_window_position(Gfx::IntPoint position)
{
client().async_set_window_position(m_client_state.page_index, position.to_type<Web::DevicePixels>());
}
void ViewImplementation::set_window_size(Gfx::IntSize size)
{
client().async_set_window_size(m_client_state.page_index, size.to_type<Web::DevicePixels>());
}
LibWeb+WebContent+WebDriver+UI: Make window rect updates asynchronous It's currently possible for window size/position updates to hang, as the underlying IPCs are synchronous. This updates the WebDriver endpoint to be async, to unblock the WebContent process while the update is ongoing. The UI process is now responsible for informing WebContent when the update is complete.
2024-10-28 23:37:11 -04:00
void ViewImplementation::did_update_window_rect()
{
client().async_did_update_window_rect(m_client_state.page_index);
}
LibWebView+WebContent+UI: Remember the current system visibility state We will want to re-inform WebContent of the system visibility state when we create a new process after a crash. This changes the IPC to just send the enum value directly, instead of a boolean, so that we can just store that enum value directly on the ViewImplementation class.
2024-11-13 11:24:16 -05:00
void ViewImplementation::set_system_visibility_state(Web::HTML::VisibilityState visibility_state)
{
m_system_visibility_state = visibility_state;
client().async_set_system_visibility_state(m_client_state.page_index, m_system_visibility_state);
}
AK+LibURL: Move AK::URL into a new URL library This URL library ends up being a relatively fundamental base library of the system, as LibCore depends on LibURL. This change has two main benefits: * Moving AK back more towards being an agnostic library that can be used between the kernel and userspace. URL has never really fit that description - and is not used in the kernel. * URL _should_ depend on LibUnicode, as it needs punnycode support. However, it's not really possible to do this inside of AK as it can't depend on any external library. This change brings us a little closer to being able to do that, but unfortunately we aren't there quite yet, as the code generators depend on LibCore.
2024-03-18 16:22:27 +13:00
void ViewImplementation::load(URL::URL const& url)
LibWebView+Ladybird: Move page loading to ViewImplementation
2023-01-12 20:30:06 +00:00
{
m_url = url;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_load_url(page_id(), url);
LibWebView+Ladybird: Move page loading to ViewImplementation
2023-01-12 20:30:06 +00:00
}
Userland+Ladybird: Always specify url to be about:srcdoc in load_html() After moving to navigables, we started reusing the code that populates session history entries with the srcdoc attribute value from iframes in `Page::load_html()` for loading HTML. This change addresses a crash in `determine_the_origin` which occurred because this method expected the URL to be `about:srcdoc` if we also provided HTML content (previously, it was the URL passed along with the HTML content into `load_html()`).
2023-09-17 17:12:17 +02:00
void ViewImplementation::load_html(StringView html)
LibWebView+Ladybird: Move page loading to ViewImplementation
2023-01-12 20:30:06 +00:00
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_load_html(page_id(), html);
LibWebView+Ladybird: Move page loading to ViewImplementation
2023-01-12 20:30:06 +00:00
}
LibWeb+LibWebView+WebContent: Add an IPC call for Navigable::reload()
2024-04-13 18:51:27 +02:00
void ViewImplementation::reload()
{
client().async_reload(page_id());
}
LibWeb+LibWebView+WebContent: Add traverse_history_by_delta() IPC call
2024-04-13 22:33:48 +02:00
void ViewImplementation::traverse_the_history_by_delta(int delta)
{
client().async_traverse_the_history_by_delta(page_id(), delta);
}
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
void ViewImplementation::zoom_in()
{
if (m_zoom_level >= ZOOM_MAX_LEVEL)
return;
LibWebView: Do floating-point-error-free zoom calculation using rounding The current min/max zoom levels are supposed to be: 30% and 500%. Before, due to floating point error accumulation in incremental addition of zoom-step into zoom-level, one extra zoom step would get allowed, enabling user to zoom 20%-to-510%. Now, using rounding, the intermediate zoom-level values should be as close to the theoretical value as FP32 can represent. E.g. zoom-level of 70% (theoretical multiplier 0.7) is 0.69... .
2024-09-18 12:23:12 +00:00
m_zoom_level = round_to<int>((m_zoom_level + ZOOM_STEP) * 100) / 100.0f;
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
update_zoom();
}
void ViewImplementation::zoom_out()
{
if (m_zoom_level <= ZOOM_MIN_LEVEL)
return;
LibWebView: Do floating-point-error-free zoom calculation using rounding The current min/max zoom levels are supposed to be: 30% and 500%. Before, due to floating point error accumulation in incremental addition of zoom-step into zoom-level, one extra zoom step would get allowed, enabling user to zoom 20%-to-510%. Now, using rounding, the intermediate zoom-level values should be as close to the theoretical value as FP32 can represent. E.g. zoom-level of 70% (theoretical multiplier 0.7) is 0.69... .
2024-09-18 12:23:12 +00:00
m_zoom_level = round_to<int>((m_zoom_level - ZOOM_STEP) * 100) / 100.0f;
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
update_zoom();
}
LibWeb+UI: Add internals API to set browser zoom
2024-12-23 22:15:06 +01:00
void ViewImplementation::set_zoom(double zoom_level)
{
m_zoom_level = max(ZOOM_MIN_LEVEL, min(zoom_level, ZOOM_MAX_LEVEL));
update_zoom();
}
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
void ViewImplementation::reset_zoom()
{
m_zoom_level = 1.0f;
update_zoom();
LibWeb+LibWebView+WebContent: Reset pinch-to-zoom state on Ctrl/Cmd+0
2025-10-09 20:29:12 +02:00
client().async_reset_zoom(m_client_state.page_index);
LibWebView+Ladybird: Move zoom logic to ViewImplementation
2023-01-12 19:49:49 +00:00
}
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
void ViewImplementation::enqueue_input_event(Web::InputEvent event)
{
// Send the next event over to the WebContent to be handled by JS. We'll later get a message to say whether JS
// prevented the default event behavior, at which point we either discard or handle that event, and then try to
// process the next one.
m_pending_input_events.enqueue(move(event));
m_pending_input_events.tail().visit(
[this](Web::KeyEvent const& event) {
LibWeb+UI: Rename ChromeInputData to BrowserInputData
2025-03-15 17:07:53 -04:00
client().async_key_event(m_client_state.page_index, event.clone_without_browser_data());
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
},
[this](Web::MouseEvent const& event) {
LibWeb+UI: Rename ChromeInputData to BrowserInputData
2025-03-15 17:07:53 -04:00
client().async_mouse_event(m_client_state.page_index, event.clone_without_browser_data());
LibWeb+LibWebView+WebContent: Add IPC to send drag-and-drop events This adds the IPC and related hooks to allow the UI to send drag-and- drop events from the UI process to the WebContent process.
2024-08-17 13:36:28 -04:00
},
[this](Web::DragEvent& event) {
LibWeb+UI: Rename ChromeInputData to BrowserInputData
2025-03-15 17:07:53 -04:00
auto cloned_event = event.clone_without_browser_data();
LibWeb+LibWebView+WebContent: Add IPC to send drag-and-drop events This adds the IPC and related hooks to allow the UI to send drag-and- drop events from the UI process to the WebContent process.
2024-08-17 13:36:28 -04:00
cloned_event.files = move(event.files);
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_drag_event(m_client_state.page_index, cloned_event);
LibWeb+UI+WebContent: Pipe pinch events from AppKit UI to WebContent
2025-10-08 23:59:50 +02:00
},
[this](Web::PinchEvent const& event) {
client().async_pinch_event(m_client_state.page_index, event);
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
});
}
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
void ViewImplementation::did_finish_handling_input_event(Badge<WebContentClient>, Web::EventResult event_result)
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
{
auto event = m_pending_input_events.dequeue();
LibWeb+LibWebView+WebContent: Return a named enum from UI event handlers UI event handlers currently return a boolean where false means the event was cancelled by a script on the page, or otherwise dropped. It has been a point of confusion for some time now, as it's not particularly clear what should be returned in some special cases, or how the UI process should handle the response. This adds an enumeration with a few states that indicate exactly how the WebContent process handled the event. This should remove all ambiguity, and let us properly handle these states going forward. There should be no behavior change with this patch. It's meant to only introduce the enum, not change any of our decisions based on the result.
2024-09-12 12:56:31 -04:00
if (event_result == Web::EventResult::Handled)
LibWeb+LibWebView+WebContent: Add IPC to send drag-and-drop events This adds the IPC and related hooks to allow the UI to send drag-and- drop events from the UI process to the WebContent process.
2024-08-17 13:36:28 -04:00
return;
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
LibWeb+LibWebView+WebContent: Add IPC to send drag-and-drop events This adds the IPC and related hooks to allow the UI to send drag-and- drop events from the UI process to the WebContent process.
2024-08-17 13:36:28 -04:00
// Here we handle events that were not consumed or cancelled by the WebContent. Propagate the event back
// to the concrete view implementation.
event.visit(
[this](Web::KeyEvent const& event) {
if (on_finish_handling_key_event)
on_finish_handling_key_event(event);
},
[this](Web::DragEvent const& event) {
if (on_finish_handling_drag_event)
on_finish_handling_drag_event(event);
},
[](auto const&) {});
LibWeb+LibWebView: Migrate Browser's input event handling to LibWebView The Serenity chrome is the only chrome thus far that sends all input key and mouse events to WebContent, including shortcut activations. This is necessary for all chromes - we must give web pages a chance to intercept input events before handling them ourselves. To make this easier for other chromes, this patch moves Serenity's input event handling to LibWebView. To do so, we add the Web::InputEvent type, which models the event data we need within LibWeb. Chromes will then be responsible for converting between this type and their native events. This class lives in LibWeb (rather than LibWebView) because the plan is to use it wholesale throughout the Page's event handler and across IPC. Right now, we still send the individual fields of the event over IPC, but it will be an easy refactor to send the event itself. We just can't do this until all chromes have been ported to this event queueing. Also note that we now only handle key input events back in the chrome. WebContent handles all mouse events that it possibly can. If it was not able to handle a mouse event, there's nothing for the chrome to do (i.e. there is no clicking, scrolling, etc. the chrome is able to do if the WebContent couldn't).
2024-03-03 22:07:49 -05:00
}
LibWebView+Ladybird: Move preferred color scheme to ViewImplementation
2023-01-12 20:44:42 +00:00
void ViewImplementation::set_preferred_color_scheme(Web::CSS::PreferredColorScheme color_scheme)
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_set_preferred_color_scheme(page_id(), color_scheme);
LibWebView+Ladybird: Move preferred color scheme to ViewImplementation
2023-01-12 20:44:42 +00:00
}
LibWeb: Add Contrast preference
2024-06-13 01:03:56 +02:00
void ViewImplementation::set_preferred_contrast(Web::CSS::PreferredContrast contrast)
{
client().async_set_preferred_contrast(page_id(), contrast);
}
LibWeb: Add motion preference This adds a motion preference to the browser UI similar to the existing ones for color scheme and contrast. Both AppKit UI and Qt UI has this new preference. The auto value is currently the same as NoPreference, follow-ups can address wiring that up to the actual preference for the OS.
2024-06-13 16:15:59 +02:00
void ViewImplementation::set_preferred_motion(Web::CSS::PreferredMotion motion)
{
client().async_set_preferred_motion(page_id(), motion);
}
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
ByteString ViewImplementation::selected_text()
LibWebView+Ladybird: Move text selection to ViewImplementation
2023-01-12 20:42:42 +00:00
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
return client().get_selected_text(page_id());
LibWebView+Ladybird: Move text selection to ViewImplementation
2023-01-12 20:42:42 +00:00
}
LibWebView: Add a helper to get selected text with collapsed whitespace
2023-10-23 16:52:57 -04:00
Optional<String> ViewImplementation::selected_text_with_whitespace_collapsed()
{
auto selected_text = MUST(Web::Infra::strip_and_collapse_whitespace(this->selected_text()));
if (selected_text.is_empty())
return OptionalNone {};
return selected_text;
}
LibWebView+Ladybird: Move text selection to ViewImplementation
2023-01-12 20:42:42 +00:00
void ViewImplementation::select_all()
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_select_all(page_id());
LibWebView+Ladybird: Move text selection to ViewImplementation
2023-01-12 20:42:42 +00:00
}
LibWeb+LibWebView+WebContent: Support case-insensitive find-in-page This allows searching for text with case-insensitivity. As this is probably what most users expect, the default behavior is changes to perform case-insensitive lookups. Chromes may add UI to change the behavior as they see fit.
2024-05-31 16:01:34 -04:00
void ViewImplementation::find_in_page(String const& query, CaseSensitivity case_sensitivity)
LibWeb+LibWebView+WebContent: Add basic find in page functionality This allows the browser to send a query to the WebContent process, which will search the page for the given string and highlight any occurrences of that string.
2024-05-29 20:09:33 +01:00
{
LibWeb+LibWebView+WebContent: Support case-insensitive find-in-page This allows searching for text with case-insensitivity. As this is probably what most users expect, the default behavior is changes to perform case-insensitive lookups. Chromes may add UI to change the behavior as they see fit.
2024-05-31 16:01:34 -04:00
client().async_find_in_page(page_id(), query, case_sensitivity);
LibWeb+LibWebView+WebContent: Add basic find in page functionality This allows the browser to send a query to the WebContent process, which will search the page for the given string and highlight any occurrences of that string.
2024-05-29 20:09:33 +01:00
}
void ViewImplementation::find_in_page_next_match()
{
client().async_find_in_page_next_match(page_id());
}
void ViewImplementation::find_in_page_previous_match()
{
client().async_find_in_page_previous_match(page_id());
}
LibWebView+Ladybird: Move get source request to ViewImplementation
2023-01-12 19:58:00 +00:00
void ViewImplementation::get_source()
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_get_source(page_id());
LibWebView+Ladybird: Move get source request to ViewImplementation
2023-01-12 19:58:00 +00:00
}
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
void ViewImplementation::inspect_dom_tree()
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_inspect_dom_tree(page_id());
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
}
LibWeb+LibWebView+WebContent: Support both inspecting/highlighting nodes Our own Inspector differs from most other DevTools implementations with regard to highlighting DOM nodes as you hover elements in the inspected DOM tree. In other implementations, as you change the hovered node, the browser will render a box model overlay onto the page for that node. We currently don't do this; we wait until you click the node, at which point we both paint the overlay and inspect the node's properties. This patch does not change that behavior, but separates the IPCs and internal tracking of inspected nodes to support the standard DevTools behavior. So the DOM document now stores an inspected node and a highlighted node. The former is used for features such as "$0" in the JavaScript console, and the latter is used for the box model overlay. Our Inspector continues to set these to the same node.
2025-02-21 09:34:02 -05:00
void ViewImplementation::inspect_accessibility_tree()
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
{
LibWeb+LibWebView+WebContent: Support both inspecting/highlighting nodes Our own Inspector differs from most other DevTools implementations with regard to highlighting DOM nodes as you hover elements in the inspected DOM tree. In other implementations, as you change the hovered node, the browser will render a box model overlay onto the page for that node. We currently don't do this; we wait until you click the node, at which point we both paint the overlay and inspect the node's properties. This patch does not change that behavior, but separates the IPCs and internal tracking of inspected nodes to support the standard DevTools behavior. So the DOM document now stores an inspected node and a highlighted node. The former is used for features such as "$0" in the JavaScript console, and the latter is used for the box model overlay. Our Inspector continues to set these to the same node.
2025-02-21 09:34:02 -05:00
client().async_inspect_accessibility_tree(page_id());
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
}
LibWeb+LibWebView+WebContent: Support both inspecting/highlighting nodes Our own Inspector differs from most other DevTools implementations with regard to highlighting DOM nodes as you hover elements in the inspected DOM tree. In other implementations, as you change the hovered node, the browser will render a box model overlay onto the page for that node. We currently don't do this; we wait until you click the node, at which point we both paint the overlay and inspect the node's properties. This patch does not change that behavior, but separates the IPCs and internal tracking of inspected nodes to support the standard DevTools behavior. So the DOM document now stores an inspected node and a highlighted node. The former is used for features such as "$0" in the JavaScript console, and the latter is used for the box model overlay. Our Inspector continues to set these to the same node.
2025-02-21 09:34:02 -05:00
void ViewImplementation::get_hovered_node_id()
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
{
LibWeb+LibWebView+WebContent: Support both inspecting/highlighting nodes Our own Inspector differs from most other DevTools implementations with regard to highlighting DOM nodes as you hover elements in the inspected DOM tree. In other implementations, as you change the hovered node, the browser will render a box model overlay onto the page for that node. We currently don't do this; we wait until you click the node, at which point we both paint the overlay and inspect the node's properties. This patch does not change that behavior, but separates the IPCs and internal tracking of inspected nodes to support the standard DevTools behavior. So the DOM document now stores an inspected node and a highlighted node. The former is used for features such as "$0" in the JavaScript console, and the latter is used for the box model overlay. Our Inspector continues to set these to the same node.
2025-02-21 09:34:02 -05:00
client().async_get_hovered_node_id(page_id());
}
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
void ViewImplementation::inspect_dom_node(Web::UniqueNodeID node_id, DOMNodeProperties::Type property_type, Optional<Web::CSS::PseudoElement> pseudo_element)
LibWeb+LibWebView+WebContent: Support both inspecting/highlighting nodes Our own Inspector differs from most other DevTools implementations with regard to highlighting DOM nodes as you hover elements in the inspected DOM tree. In other implementations, as you change the hovered node, the browser will render a box model overlay onto the page for that node. We currently don't do this; we wait until you click the node, at which point we both paint the overlay and inspect the node's properties. This patch does not change that behavior, but separates the IPCs and internal tracking of inspected nodes to support the standard DevTools behavior. So the DOM document now stores an inspected node and a highlighted node. The former is used for features such as "$0" in the JavaScript console, and the latter is used for the box model overlay. Our Inspector continues to set these to the same node.
2025-02-21 09:34:02 -05:00
{
LibDevTools+LibWebView+WebContent: Selectively fetch DOM node properties When we inspect a DOM node, we currently serialize many properties for that node, including its layout, computed style, used fonts, etc. Now that we aren't piggy-backing on the Inspector interface, we can instead only serialize the specific information required by DevTools.
2025-03-19 15:50:56 -04:00
client().async_inspect_dom_node(page_id(), property_type, node_id, pseudo_element);
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
}
void ViewImplementation::clear_inspected_dom_node()
{
LibDevTools+LibWebView+WebContent: Selectively fetch DOM node properties When we inspect a DOM node, we currently serialize many properties for that node, including its layout, computed style, used fonts, etc. Now that we aren't piggy-backing on the Inspector interface, we can instead only serialize the specific information required by DevTools.
2025-03-19 15:50:56 -04:00
client().async_clear_inspected_dom_node(page_id());
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
}
LibWeb/CSS: Move and rename PseudoElement types to prep for code gen The upcoming generated types will match those for pseudo-classes: A PseudoElementSelector type, that then holds a PseudoElement enum defining what it is. That enum will be at the top level in the Web::CSS namespace. In order to keep the diffs clearer, this commit renames and moves the types, and then a following one will replace the handwritten enum with a generated one.
2025-03-20 16:56:46 +00:00
void ViewImplementation::highlight_dom_node(Web::UniqueNodeID node_id, Optional<Web::CSS::PseudoElement> pseudo_element)
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
{
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_highlight_dom_node(page_id(), node_id, pseudo_element);
LibWeb+LibWebView+WebContent: Support both inspecting/highlighting nodes Our own Inspector differs from most other DevTools implementations with regard to highlighting DOM nodes as you hover elements in the inspected DOM tree. In other implementations, as you change the hovered node, the browser will render a box model overlay onto the page for that node. We currently don't do this; we wait until you click the node, at which point we both paint the overlay and inspect the node's properties. This patch does not change that behavior, but separates the IPCs and internal tracking of inspected nodes to support the standard DevTools behavior. So the DOM document now stores an inspected node and a highlighted node. The former is used for features such as "$0" in the JavaScript console, and the latter is used for the box model overlay. Our Inspector continues to set these to the same node.
2025-02-21 09:34:02 -05:00
}
void ViewImplementation::clear_highlighted_dom_node()
{
highlight_dom_node(0, {});
LibWebView+Ladybird: Move DOM inspection helpers to ViewImplementation
2023-01-12 20:22:14 +00:00
}
LibWeb+LibWebView+WebContent: Inform the UI about DOM mutations This will allow our DevTools server to inform the Firefox DevTools client about DOM mutations.
2025-03-06 17:32:43 -05:00
void ViewImplementation::set_listen_for_dom_mutations(bool listen_for_dom_mutations)
{
client().async_set_listen_for_dom_mutations(page_id(), listen_for_dom_mutations);
}
LibDevTools+LibWebView+WebContent: Implement getting DOM node inner HTML This is used by DevTools to copy the inner HTML to the clipboard.
2025-03-10 18:15:31 -04:00
void ViewImplementation::get_dom_node_inner_html(Web::UniqueNodeID node_id)
{
client().async_get_dom_node_inner_html(page_id(), node_id);
}
LibDevTools+LibWebView+WebContent: Implement editing DOM node HTML These commands are used for the "Edit As HTML" feature in DevTools. This renames our existing HTML getter IPC to indicate that it is for outer HTML. DevTools will need a separate inner HTML getter.
2025-03-10 17:36:41 -04:00
void ViewImplementation::get_dom_node_outer_html(Web::UniqueNodeID node_id)
{
client().async_get_dom_node_outer_html(page_id(), node_id);
}
void ViewImplementation::set_dom_node_outer_html(Web::UniqueNodeID node_id, String const& html)
{
client().async_set_dom_node_outer_html(page_id(), node_id, html);
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void ViewImplementation::set_dom_node_text(Web::UniqueNodeID node_id, String const& text)
LibWebView+WebContent: Add APIs to manipulate DOM nodes This adds APIs to allow Ispector clients to: * Change a DOM text or comment node's text data. * Add, replace, or remove a DOM element's attribute. * Change a DOM element's tag.
2023-11-19 10:42:11 -05:00
{
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_set_dom_node_text(page_id(), node_id, text);
LibWebView+WebContent: Add APIs to manipulate DOM nodes This adds APIs to allow Ispector clients to: * Change a DOM text or comment node's text data. * Add, replace, or remove a DOM element's attribute. * Change a DOM element's tag.
2023-11-19 10:42:11 -05:00
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void ViewImplementation::set_dom_node_tag(Web::UniqueNodeID node_id, String const& name)
LibWebView+WebContent: Add APIs to manipulate DOM nodes This adds APIs to allow Ispector clients to: * Change a DOM text or comment node's text data. * Add, replace, or remove a DOM element's attribute. * Change a DOM element's tag.
2023-11-19 10:42:11 -05:00
{
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_set_dom_node_tag(page_id(), node_id, name);
LibWebView+WebContent: Add APIs to manipulate DOM nodes This adds APIs to allow Ispector clients to: * Change a DOM text or comment node's text data. * Add, replace, or remove a DOM element's attribute. * Change a DOM element's tag.
2023-11-19 10:42:11 -05:00
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void ViewImplementation::add_dom_node_attributes(Web::UniqueNodeID node_id, ReadonlySpan<Attribute> attributes)
LibWebView+WebContent: Add a WebContent IPC to add DOM attributes
2023-12-05 16:49:47 -05:00
{
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_add_dom_node_attributes(page_id(), node_id, attributes);
LibWebView+WebContent: Add a WebContent IPC to add DOM attributes
2023-12-05 16:49:47 -05:00
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void ViewImplementation::replace_dom_node_attribute(Web::UniqueNodeID node_id, String const& name, ReadonlySpan<Attribute> replacement_attributes)
LibWebView+WebContent: Add APIs to manipulate DOM nodes This adds APIs to allow Ispector clients to: * Change a DOM text or comment node's text data. * Add, replace, or remove a DOM element's attribute. * Change a DOM element's tag.
2023-11-19 10:42:11 -05:00
{
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_replace_dom_node_attribute(page_id(), node_id, name, replacement_attributes);
LibWebView+WebContent: Add APIs to manipulate DOM nodes This adds APIs to allow Ispector clients to: * Change a DOM text or comment node's text data. * Add, replace, or remove a DOM element's attribute. * Change a DOM element's tag.
2023-11-19 10:42:11 -05:00
}
LibWeb: Make DOM Node unique IDs strongly typed (and 64 bit) This is strictly nicer than passing them around as i32 everywhere, and by switching to i64 as the underlying type, ID allocation becomes as simple as incrementing an integer.
2024-10-20 10:37:44 +02:00
void ViewImplementation::create_child_element(Web::UniqueNodeID node_id)
LibWebView+WebContent: Add WebContent IPC to create children DOM nodes This adds IPC to create append a child <div> element or a text node to a DOM node.
2023-12-07 11:00:57 -05:00
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_create_child_element(page_id(), node_id);
LibWebView+WebContent: Add WebContent IPC to create children DOM nodes This adds IPC to create append a child <div> element or a text node to a DOM node.
2023-12-07 11:00:57 -05:00
}
LibWeb: Make DOM Node unique IDs strongly typed (and 64 bit) This is strictly nicer than passing them around as i32 everywhere, and by switching to i64 as the underlying type, ID allocation becomes as simple as incrementing an integer.
2024-10-20 10:37:44 +02:00
void ViewImplementation::create_child_text_node(Web::UniqueNodeID node_id)
LibWebView+WebContent: Add WebContent IPC to create children DOM nodes This adds IPC to create append a child <div> element or a text node to a DOM node.
2023-12-07 11:00:57 -05:00
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_create_child_text_node(page_id(), node_id);
LibWebView+WebContent: Add WebContent IPC to create children DOM nodes This adds IPC to create append a child <div> element or a text node to a DOM node.
2023-12-07 11:00:57 -05:00
}
LibDevTools+LibWebView+WebContent: Implement moving DOM nodes This allows for click-and-dragging DOM nodes in DevTools to move them.
2025-03-10 18:01:29 -04:00
void ViewImplementation::insert_dom_node_before(Web::UniqueNodeID node_id, Web::UniqueNodeID parent_node_id, Optional<Web::UniqueNodeID> sibling_node_id)
{
client().async_insert_dom_node_before(page_id(), node_id, parent_node_id, sibling_node_id);
}
LibWeb: Make DOM Node unique IDs strongly typed (and 64 bit) This is strictly nicer than passing them around as i32 everywhere, and by switching to i64 as the underlying type, ID allocation becomes as simple as incrementing an integer.
2024-10-20 10:37:44 +02:00
void ViewImplementation::clone_dom_node(Web::UniqueNodeID node_id)
LibWebView+WebContent: Add a WebContent IPC to clone a DOM node
2023-12-07 11:12:43 -05:00
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_clone_dom_node(page_id(), node_id);
LibWebView+WebContent: Add a WebContent IPC to clone a DOM node
2023-12-07 11:12:43 -05:00
}
LibWeb: Make DOM Node unique IDs strongly typed (and 64 bit) This is strictly nicer than passing them around as i32 everywhere, and by switching to i64 as the underlying type, ID allocation becomes as simple as incrementing an integer.
2024-10-20 10:37:44 +02:00
void ViewImplementation::remove_dom_node(Web::UniqueNodeID node_id)
LibWebView+WebContent: Add a WebContent IPC to remove a DOM node The FIXME added to ConnectionFromClient::remove_dom_node is copied from Web::EditEventHandler. The same behavior is observed here, with many lingering Layout::TextNodes, for example.
2023-12-05 14:59:54 -05:00
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_remove_dom_node(page_id(), node_id);
LibWebView+WebContent: Add a WebContent IPC to remove a DOM node The FIXME added to ConnectionFromClient::remove_dom_node is copied from Web::EditEventHandler. The same behavior is observed here, with many lingering Layout::TextNodes, for example.
2023-12-05 14:59:54 -05:00
}
Inspector: Add a basic style sheet inspector Choosing options from the `<select>` will load and display that style sheet's source text, with some checks to make sure that the text that just loaded is the one we currently want. The UI is a little goofy when scrolling, as it uses `position: sticky` which we don't implement yet. But that's just more motivation to implement it! :^)
2024-08-23 11:18:35 +01:00
void ViewImplementation::list_style_sheets()
{
client().async_list_style_sheets(page_id());
}
void ViewImplementation::request_style_sheet_source(Web::CSS::StyleSheetIdentifier const& identifier)
{
client().async_request_style_sheet_source(page_id(), identifier);
}
Everywhere: Rename {Deprecated => Byte}String This commit un-deprecates DeprecatedString, and repurposes it as a byte string. As the null state has already been removed, there are no other particularly hairy blockers in repurposing this type as a byte string (what it _really_ is). This commit is auto-generated: $ xs=$(ack -l \bDeprecatedString\b\|deprecated_string AK Userland \ Meta Ports Ladybird Tests Kernel) $ perl -pie 's/\bDeprecatedString\b/ByteString/g; s/deprecated_string/byte_string/g' $xs $ clang-format --style=file -i \ $(git diff --name-only | grep \.cpp\|\.h) $ gn format $(git ls-files '*.gn' '*.gni')
2023-12-16 17:49:34 +03:30
void ViewImplementation::debug_request(ByteString const& request, ByteString const& argument)
LibWebView+Ladybird: Move debug request to ViewImplementation
2023-01-12 20:34:08 +00:00
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_debug_request(page_id(), request, argument);
LibWebView+Ladybird: Move debug request to ViewImplementation
2023-01-12 20:34:08 +00:00
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void ViewImplementation::run_javascript(String const& js_source)
LibWebView+Ladybird: Move running JavaScript to ViewImplementation
2023-01-12 20:39:08 +00:00
{
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_run_javascript(page_id(), js_source);
LibWebView+Ladybird: Move running JavaScript to ViewImplementation
2023-01-12 20:39:08 +00:00
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void ViewImplementation::js_console_input(String const& js_source)
Ladybird: Move ownership of the JS console/inspector to the tab object This is to match Browser, where ownership of all "subwidgets" is placed on the tab as well. This further lets us align the web view callbacks to match Browser's OOPWV as well, which will later let us move them into the base LibWebView class.
2023-05-17 11:54:36 -04:00
{
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_js_console_input(page_id(), js_source);
Ladybird: Move ownership of the JS console/inspector to the tab object This is to match Browser, where ownership of all "subwidgets" is placed on the tab as well. This further lets us align the web view callbacks to match Browser's OOPWV as well, which will later let us move them into the base LibWebView class.
2023-05-17 11:54:36 -04:00
}
void ViewImplementation::js_console_request_messages(i32 start_index)
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_js_console_request_messages(page_id(), start_index);
Ladybird: Move ownership of the JS console/inspector to the tab object This is to match Browser, where ownership of all "subwidgets" is placed on the tab as well. This further lets us align the web view callbacks to match Browser's OOPWV as well, which will later let us move them into the base LibWebView class.
2023-05-17 11:54:36 -04:00
}
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
void ViewImplementation::alert_closed()
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_alert_closed(page_id());
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
}
void ViewImplementation::confirm_closed(bool accepted)
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_confirm_closed(page_id(), accepted);
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void ViewImplementation::prompt_closed(Optional<String> const& response)
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
{
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_prompt_closed(page_id(), response);
Ladybird+LibWebView: Migrate dialog APIs to LibWebView callbacks
2023-05-17 14:23:34 -04:00
}
LibWeb: Allow input color to give continuous updates
2023-12-11 06:53:10 +01:00
void ViewImplementation::color_picker_update(Optional<Color> picked_color, Web::HTML::ColorPickerUpdateState state)
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
{
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_color_picker_update(page_id(), picked_color, state);
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
}
LibWeb+LibWebView+WebContent: Implement more <input type=file> behavior We had previous implemented some plumbing for file input elements in commit 636602a54e55945f7394805975a69dc40934331c. This implements the return path for chromes to inform WebContent of the file(s) the user selected. This patch includes a dummy implementation for headless-browser to enable testing.
2024-02-25 13:02:47 -05:00
void ViewImplementation::file_picker_closed(Vector<Web::HTML::SelectedFile> selected_files)
{
client().async_file_picker_closed(page_id(), move(selected_files));
}
LibWeb: Refactor SelectItem to allow selecting options without value Currently the `<select>` dropdown IPC uses the option value attr to find which option is selected. This won't work when options don't have values or when multiple options have the same value. Also the `SelectItem` contained so weird recursive structures that are impossible to create with HTML. So I refactored `SelectItem` as a variant, and gave the options a unique id. The id is send back to `HTMLSelectElement` so it can find out exactly which option element is selected.
2024-04-03 19:19:08 +02:00
void ViewImplementation::select_dropdown_closed(Optional<u32> const& selected_item_id)
Ladybird+LibWeb: Add basic select element support
2023-12-07 15:53:49 +01:00
{
LibWeb: Refactor SelectItem to allow selecting options without value Currently the `<select>` dropdown IPC uses the option value attr to find which option is selected. This won't work when options don't have values or when multiple options have the same value. Also the `SelectItem` contained so weird recursive structures that are impossible to create with HTML. So I refactored `SelectItem` as a variant, and gave the options a unique id. The id is send back to `HTMLSelectElement` so it can find out exactly which option element is selected.
2024-04-03 19:19:08 +02:00
client().async_select_dropdown_closed(page_id(), selected_item_id);
Ladybird+LibWeb: Add basic select element support
2023-12-07 15:53:49 +01:00
}
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
void ViewImplementation::paste_text_from_clipboard()
Ladybird+LibWeb+WebContent: Add context menu controls for muting audio
2023-06-16 11:29:54 -04:00
{
LibWebView+UI: Move clipboard handling from the WebView to the App Clipboard handling largely has nothing to do with the individual web views. Rather, we interact with the system clipboard at the application level. So let's move these implementations to the Application.
2025-09-18 08:16:36 -04:00
client().async_paste(page_id(), Application::the().clipboard_text());
Ladybird+LibWeb+WebContent: Add context menu controls for muting audio
2023-06-16 11:29:54 -04:00
}
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
void ViewImplementation::retrieved_clipboard_entries(u64 request_id, ReadonlySpan<Web::Clipboard::SystemClipboardItem> items)
LibWeb+WebContent: Add APIs to control video playback state This allows for the browser process to control the play/pause state, whether we paint user agent controls on the video, and whether the video loops when it finishes playing.
2023-05-15 11:17:58 -04:00
{
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
client().async_retrieved_clipboard_entries(page_id(), request_id, items);
LibWeb+WebContent: Add APIs to control video playback state This allows for the browser process to control the play/pause state, whether we paint user agent controls on the video, and whether the video loops when it finishes playing.
2023-05-15 11:17:58 -04:00
}
LibWeb+LibWebView+WebContent: Support muting an entire page This adds an IPC for chromes to mute a tab. When muted, we trigger an internal volume change notification and indicate that the user agent has overriden the media volume.
2024-03-30 09:41:15 -04:00
void ViewImplementation::toggle_page_mute_state()
{
m_mute_state = Web::HTML::invert_mute_state(m_mute_state);
client().async_toggle_page_mute_state(page_id());
}
LibWeb+LibWebView+WebContent: Inform chromes when audio is played/paused Most browsers have some indicator when audio is playing in a tab, which makes it easier to find that tab and mute unwanted audio. This adds an IPC to allow the Ladybird chromes to do something similar.
2024-03-26 19:27:06 -04:00
void ViewImplementation::did_change_audio_play_state(Badge<WebContentClient>, Web::HTML::AudioPlayState play_state)
{
LibWebView: Handle mutliple audio tracks when audio play state changes For example, if a page has multiple audio elements all actively playing audio, we don't want to broadcast a play state change when only one of them stop playing.
2024-03-30 09:34:23 -04:00
bool state_changed = false;
switch (play_state) {
case Web::HTML::AudioPlayState::Paused:
if (--m_number_of_elements_playing_audio == 0) {
m_audio_play_state = play_state;
state_changed = true;
}
break;
case Web::HTML::AudioPlayState::Playing:
if (m_number_of_elements_playing_audio++ == 0) {
m_audio_play_state = play_state;
state_changed = true;
}
break;
}
LibWeb+LibWebView+WebContent: Inform chromes when audio is played/paused Most browsers have some indicator when audio is playing in a tab, which makes it easier to find that tab and mute unwanted audio. This adds an IPC to allow the Ladybird chromes to do something similar.
2024-03-26 19:27:06 -04:00
LibWebView: Handle mutliple audio tracks when audio play state changes For example, if a page has multiple audio elements all actively playing audio, we don't want to broadcast a play state change when only one of them stop playing.
2024-03-30 09:34:23 -04:00
if (state_changed && on_audio_play_state_changed)
LibWeb+LibWebView+WebContent: Inform chromes when audio is played/paused Most browsers have some indicator when audio is playing in a tab, which makes it easier to find that tab and mute unwanted audio. This adds an IPC to allow the Ladybird chromes to do something similar.
2024-03-26 19:27:06 -04:00
on_audio_play_state_changed(m_audio_play_state);
}
LibWeb+LibWebView+WebContent: Add did_update_navigation_buttons_state() It is going to be used to communicate whether it is possible to navigate back or forward after session history stored on browser side will no longer be used to driver navigation.
2024-04-13 23:12:55 +02:00
void ViewImplementation::did_update_navigation_buttons_state(Badge<WebContentClient>, bool back_enabled, bool forward_enabled) const
{
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
m_navigate_back_action->set_enabled(back_enabled);
m_navigate_forward_action->set_enabled(forward_enabled);
LibWeb+LibWebView+WebContent: Add did_update_navigation_buttons_state() It is going to be used to communicate whether it is possible to navigate back or forward after session history stored on browser side will no longer be used to driver navigation.
2024-04-13 23:12:55 +02:00
}
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
void ViewImplementation::did_allocate_backing_stores(Badge<WebContentClient>, i32 front_bitmap_id, Gfx::ShareableBitmap const& front_bitmap, i32 back_bitmap_id, Gfx::ShareableBitmap const& back_bitmap)
Ladybird+LibWebView: Move backing store management code to LibWebView This lets us share this code on all platforms, and makes resizing the window much faster on SerenityOS as well. :^)
2023-05-15 07:59:51 +02:00
{
if (m_client_state.has_usable_bitmap) {
// NOTE: We keep the outgoing front bitmap as a backup so we have something to paint until we get a new one.
m_backup_bitmap = m_client_state.front_bitmap.bitmap;
m_backup_bitmap_size = m_client_state.front_bitmap.last_painted_size;
}
m_client_state.has_usable_bitmap = false;
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
m_client_state.front_bitmap.bitmap = front_bitmap.bitmap();
m_client_state.front_bitmap.id = front_bitmap_id;
m_client_state.back_bitmap.bitmap = back_bitmap.bitmap();
m_client_state.back_bitmap.id = back_bitmap_id;
}
Ladybird+LibWebView: Move backing store management code to LibWebView This lets us share this code on all platforms, and makes resizing the window much faster on SerenityOS as well. :^)
2023-05-15 07:59:51 +02:00
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
#ifdef AK_OS_MACOS
void ViewImplementation::did_allocate_iosurface_backing_stores(i32 front_id, Core::MachPort&& front_port, i32 back_id, Core::MachPort&& back_port)
{
if (m_client_state.has_usable_bitmap) {
// NOTE: We keep the outgoing front bitmap as a backup so we have something to paint until we get a new one.
m_backup_bitmap = m_client_state.front_bitmap.bitmap;
m_backup_bitmap_size = m_client_state.front_bitmap.last_painted_size;
}
m_client_state.has_usable_bitmap = false;
auto front_iosurface = Core::IOSurfaceHandle::from_mach_port(move(front_port));
auto back_iosurface = Core::IOSurfaceHandle::from_mach_port(move(back_port));
auto front_size = Gfx::IntSize { front_iosurface.width(), front_iosurface.height() };
auto back_size = Gfx::IntSize { back_iosurface.width(), back_iosurface.height() };
Everywhere: Pass backing store into Navigable::paint() ...instead of Gfx::Bitmap, which makes it possible to access and directly paint into IOSurface on macOS.
2024-06-25 16:43:39 +02:00
auto bytes_per_row = front_iosurface.bytes_per_row();
Everywhere: Run clang-format The following command was used to clang-format these files: clang-format-19 -i $(find . \ -not \( -path "./\.*" -prune \) \ -not \( -path "./Build/*" -prune \) \ -not \( -path "./Toolchain/*" -prune \) \ -type f -name "*.cpp" -o -name "*.mm" -o -name "*.h")
2024-12-27 18:47:33 -05:00
auto front_bitmap = Gfx::Bitmap::create_wrapper(Gfx::BitmapFormat::BGRA8888, Gfx::AlphaType::Premultiplied, front_size, bytes_per_row, front_iosurface.data(), [handle = move(front_iosurface)] { });
auto back_bitmap = Gfx::Bitmap::create_wrapper(Gfx::BitmapFormat::BGRA8888, Gfx::AlphaType::Premultiplied, back_size, bytes_per_row, back_iosurface.data(), [handle = move(back_iosurface)] { });
Everywhere: Use IOSurface as backing store on macOS Using mmap-allocated memory for backing stores does not allow us to benefit from using GPU-accelerated painting, because all the performance increase we get is mostly negated by reading the GPU-allocated texture back into RAM, so it can be shared with the browser process. With IOSurface, we get a framebuffer that is both shareable between processes and can be used as underlying memory for an OpenGL/Metal texture. This change does not yet benefit from using IOSurface and merely wraps them into Gfx::Bitmap to be used by the CPU painter.
2024-06-20 21:34:51 +03:00
m_client_state.front_bitmap.bitmap = front_bitmap.release_value_but_fixme_should_propagate_errors();
m_client_state.front_bitmap.id = front_id;
m_client_state.back_bitmap.bitmap = back_bitmap.release_value_but_fixme_should_propagate_errors();
m_client_state.back_bitmap.id = back_id;
}
#endif
LibWebView+UI: Generate the zoom menu
2025-09-10 07:23:15 -04:00
void ViewImplementation::update_zoom()
{
if (m_zoom_level != 1.0f) {
m_reset_zoom_action->set_text(MUST(String::formatted("{}%", round_to<int>(m_zoom_level * 100))));
m_reset_zoom_action->set_visible(true);
} else {
m_reset_zoom_action->set_visible(false);
}
client().async_set_device_pixels_per_css_pixel(m_client_state.page_index, m_device_pixel_ratio * m_zoom_level);
}
LibWebView+WebContent: Move backing store allocation into WebContent In the upcoming changes, we are going to switch macOS to using an IOSurface for the backing store. This change will simplify the process of sharing an IOSurface between processes because we already have the MachPortServer running in the browser, and WebContent knows how to locate the corresponding server.
2024-06-17 18:50:57 +03:00
void ViewImplementation::handle_resize()
{
client().async_set_viewport_size(page_id(), this->viewport_size());
Ladybird+LibWebView: Move backing store management code to LibWebView This lets us share this code on all platforms, and makes resizing the window much faster on SerenityOS as well. :^)
2023-05-15 07:59:51 +02:00
}
LibWebView+UI: Handle common WebView client initialization in LibWebView No need to have every UI manually implement these common steps.
2024-11-13 16:35:17 -05:00
void ViewImplementation::initialize_client(CreateNewClient create_new_client)
{
if (create_new_client == CreateNewClient::Yes) {
m_client_state = {};
LibWebView: Create a spare WebContent process Since cross-site navigation is a pretty frequent task, creating a spare process is commonplace in other browsers to reduce the overhead of directing the target site to a new process. We store this process on the WebView application. If it is unavailable, we queue a task to create it later.
2025-03-09 18:01:25 -04:00
// FIXME: Fail to open the tab, rather than crashing the whole application if this fails.
m_client_state.client = Application::the().launch_web_content_process(*this).release_value_but_fixme_should_propagate_errors();
LibWebView+UI: Handle common WebView client initialization in LibWebView No need to have every UI manually implement these common steps.
2024-11-13 16:35:17 -05:00
} else {
m_client_state.client->register_view(m_client_state.page_index, *this);
}
m_client_state.client->on_web_content_process_crash = [this] {
Core::deferred_invoke([this] {
handle_web_content_process_crash();
if (on_web_content_crashed)
on_web_content_crashed();
});
};
m_client_state.client_handle = MUST(Web::Crypto::generate_random_uuid());
client().async_set_window_handle(m_client_state.page_index, m_client_state.client_handle);
client().async_set_device_pixels_per_css_pixel(m_client_state.page_index, m_device_pixel_ratio);
LibWebView+WebContent: Make it possible to change the painting interval This allows us to paint at the refresh rate of the screen. The default is 60, as before, in case it never gets set by anything.
2025-07-25 13:10:00 +01:00
client().async_set_maximum_frames_per_second(m_client_state.page_index, m_maximum_frames_per_second);
LibWebView+UI: Handle common WebView client initialization in LibWebView No need to have every UI manually implement these common steps.
2024-11-13 16:35:17 -05:00
client().async_set_system_visibility_state(m_client_state.page_index, m_system_visibility_state);
LibWebView+UI: Rename ChromeOptions to BrowserOptions
2025-03-15 16:56:52 -04:00
if (auto webdriver_content_ipc_path = Application::browser_options().webdriver_content_ipc_path; webdriver_content_ipc_path.has_value())
LibWebView+UI: Handle common WebView client initialization in LibWebView No need to have every UI manually implement these common steps.
2024-11-13 16:35:17 -05:00
client().async_connect_to_webdriver(m_client_state.page_index, *webdriver_content_ipc_path);
LibWebView+UI: Generate the application debug menu By migrating the debug menu to LibWebView, the AppKit and Qt UIs are now in sync - the AppKit UI was previously missing some actions. Further, this inadvertently fixes bugs around applying debug settings to new web views, especially across site-isolated processes. We were previously not applying settings appropriately; this now "just works" in the LibWebView infra.
2025-09-03 09:00:52 -04:00
Application::the().apply_view_options({}, *this);
LibWebView+WebContent+UI: Migrate to the new autoplay settings This removes the old autoplay allowlist file in favor of the new site setting. We still support the command-line flag to enable autoplay globally, as this is needed for WPT.
2025-03-29 08:19:00 -04:00
LibWebView: Add defaultZoomLevelFactor setting and necessary plumbing
2025-08-23 11:15:31 -05:00
default_zoom_level_factor_changed();
LibWeb+LibWebView+UI: Migrate to LibWebView's language settings
2025-04-03 13:53:02 -04:00
languages_changed();
LibWebView+WebContent+UI: Migrate to the new autoplay settings This removes the old autoplay allowlist file in favor of the new site setting. We still support the command-line flag to enable autoplay globally, as this is needed for WPT.
2025-03-29 08:19:00 -04:00
autoplay_settings_changed();
LibWeb+LibWebView+WebContent: Replace DNT with GPC Global Privacy Control aims to be a replacement for Do Not Track. DNT ended up not being a great solution, as it wasn't enforced by law. This actually resulted in the DNT header serving as an extra fingerprinting data point. GPC is becoming enforced by law in USA states such as California and Colorado. CA is further working on a bill which requires that browsers implement such an opt-out preference signal (OOPS): https://cppa.ca.gov/announcements/2025/20250911.html This patch replaces DNT with GPC and hooks up the associated settings.
2025-04-02 09:30:34 -04:00
global_privacy_control_changed();
LibWebView+UI: Handle common WebView client initialization in LibWebView No need to have every UI manually implement these common steps.
2024-11-13 16:35:17 -05:00
}
LibWebView: Make loading an error page after a crash optional We won't need this in headless-browser (who isn't calling this helper yet).
2024-11-12 08:43:37 -05:00
void ViewImplementation::handle_web_content_process_crash(LoadErrorPage load_error_page)
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
{
LibWebView: Log the last URL we loaded when WebContent crashes We display this URL in the error page, but let's log it for headless- browser as well.
2024-11-12 08:44:11 -05:00
dbgln("\033[31;1mWebContent process crashed!\033[0m Last page loaded: {}", m_url);
Documentation: Make updates to align better with new issue template
2024-07-30 14:59:30 +09:00
dbgln("Consider raising an issue at https://github.com/LadybirdBrowser/ladybird/issues/new/choose");
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
LibWebView: Don't re-create WebContent proceses when repeatedly crashing Serenity handles this in the SystemServer already, but the simplest place to put this logic is the ViewImplementation base class. This is trivial to see when running Ladybird without SERENTIY_SOURCE_DIR set, or set improperly.
2023-05-27 10:46:45 -06:00
++m_crash_count;
constexpr size_t max_reasonable_crash_count = 5U;
if (m_crash_count >= max_reasonable_crash_count) {
dbgln("WebContent has crashed {} times in quick succession! Not restarting...", m_crash_count);
m_repeated_crash_timer->stop();
return;
}
m_repeated_crash_timer->restart();
Ladybird: Add ability to create a tab without creating a new WebContent
2024-01-30 09:12:14 -07:00
initialize_client();
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
VERIFY(m_client_state.client);
// Don't keep a stale backup bitmap around.
m_backup_bitmap = nullptr;
handle_resize();
LibWebView: Make loading an error page after a crash optional We won't need this in headless-browser (who isn't calling this helper yet).
2024-11-12 08:43:37 -05:00
if (load_error_page == LoadErrorPage::Yes) {
StringBuilder builder;
UI: Style the crash page and update error page image - Modified the error page - changed the error/crash page Co-authored-by: notnotnescap <97590612+nescapp@users.noreply.github.com>
2025-03-26 13:37:00 +01:00
builder.append("<!DOCTYPE html>"sv);
builder.append("<html lang=\"en\"><head><meta charset=\"UTF-8\"><title>Error!</title><style>"
":root { color-scheme: light dark; font-family: system-ui, sans-serif; }"
LibWebView+Base: Remove unnecessary scrollbar from error pages I've been looking at the crash-page too much recently and the slight scrollbar caused by the padding has been annoying me.
2025-09-06 17:33:56 +02:00
"body { display: flex; flex-direction: column; align-items: center; justify-content: center; min-height: 100vh; box-sizing: border-box; margin: 0; padding: 1rem; text-align: center; }"
UI: Style the crash page and update error page image - Modified the error page - changed the error/crash page Co-authored-by: notnotnescap <97590612+nescapp@users.noreply.github.com>
2025-03-26 13:37:00 +01:00
"header { display: flex; flex-direction: column; align-items: center; gap: 2rem; margin-bottom: 1rem; }"
"svg { height: 64px; width: auto; stroke: currentColor; fill: none; stroke-width: 1.5; stroke-linecap: round; stroke-linejoin: round; }"
"h1 { margin: 0; font-size: 1.5rem; }"
"p { font-size: 1rem; color: #555; }"
"</style></head><body>"sv);
builder.append("<header>"sv);
UI: Fix new error page
2025-03-26 22:46:48 +01:00
builder.append("<svg xmlns=\"http://www.w3.org/2000/svg\" viewBox=\"0 0 17.5 21.5\">"sv);
UI: Style the crash page and update error page image - Modified the error page - changed the error/crash page Co-authored-by: notnotnescap <97590612+nescapp@users.noreply.github.com>
2025-03-26 13:37:00 +01:00
builder.append("<path class=\"b\" d=\"M11.75.75h-9c-1.1 0-2 .9-2 2v16c0 1.1.9 2 2 2h12c1.1 0 2-.9 2-2v-13l-5-5z\"/>"sv);
builder.append("<path class=\"b\" d=\"M10.75.75v4c0 1.1.9 2 2 2h4M4.75 9.75l2 2M10.75 9.75l2 2M12.75 9.75l-2 2M6.75 9.75l-2 2M5.75 16.75c1-2.67 5-2.67 6 0\"/></svg>"sv);
LibWebView: Make loading an error page after a crash optional We won't need this in headless-browser (who isn't calling this helper yet).
2024-11-12 08:43:37 -05:00
auto escaped_url = escape_html_entities(m_url.to_byte_string());
UI: Fix new error page
2025-03-26 22:46:48 +01:00
builder.append("<h1>Ladybird flew off-course!</h1>"sv);
builder.appendff("<p>The web page <a href=\"{}\">{}</a> has crashed.<br><br>You can reload the page to try again.</p>", escaped_url, escaped_url);
LibWebView: Make loading an error page after a crash optional We won't need this in headless-browser (who isn't calling this helper yet).
2024-11-12 08:43:37 -05:00
builder.append("</body></html>"sv);
load_html(builder.to_byte_string());
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
}
}
LibWebView: Add defaultZoomLevelFactor setting and necessary plumbing
2025-08-23 11:15:31 -05:00
void ViewImplementation::default_zoom_level_factor_changed()
{
auto const default_zoom_level_factor = Application::settings().default_zoom_level_factor();
set_zoom(default_zoom_level_factor);
}
LibWeb+LibWebView+UI: Migrate to LibWebView's language settings
2025-04-03 13:53:02 -04:00
void ViewImplementation::languages_changed()
{
auto const& languages = Application::settings().languages();
client().async_set_preferred_languages(page_id(), languages);
}
LibWebView+WebContent+UI: Migrate to the new autoplay settings This removes the old autoplay allowlist file in favor of the new site setting. We still support the command-line flag to enable autoplay globally, as this is needed for WPT.
2025-03-29 08:19:00 -04:00
void ViewImplementation::autoplay_settings_changed()
{
auto const& autoplay_settings = Application::settings().autoplay_settings();
auto const& web_content_options = Application::web_content_options();
if (autoplay_settings.enabled_globally || web_content_options.enable_autoplay == EnableAutoplay::Yes)
client().async_set_autoplay_allowed_on_all_websites(page_id());
else
client().async_set_autoplay_allowlist(page_id(), autoplay_settings.site_filters.values());
}
LibWeb+LibWebView+WebContent: Replace DNT with GPC Global Privacy Control aims to be a replacement for Do Not Track. DNT ended up not being a great solution, as it wasn't enforced by law. This actually resulted in the DNT header serving as an extra fingerprinting data point. GPC is becoming enforced by law in USA states such as California and Colorado. CA is further working on a bill which requires that browsers implement such an opt-out preference signal (OOPS): https://cppa.ca.gov/announcements/2025/20250911.html This patch replaces DNT with GPC and hooks up the associated settings.
2025-04-02 09:30:34 -04:00
void ViewImplementation::global_privacy_control_changed()
LibWebView: Add do-not-track setting to about:settings
2025-04-02 09:47:44 -04:00
{
LibWeb+LibWebView+WebContent: Replace DNT with GPC Global Privacy Control aims to be a replacement for Do Not Track. DNT ended up not being a great solution, as it wasn't enforced by law. This actually resulted in the DNT header serving as an extra fingerprinting data point. GPC is becoming enforced by law in USA states such as California and Colorado. CA is further working on a bill which requires that browsers implement such an opt-out preference signal (OOPS): https://cppa.ca.gov/announcements/2025/20250911.html This patch replaces DNT with GPC and hooks up the associated settings.
2025-04-02 09:30:34 -04:00
auto global_privacy_control = Application::settings().global_privacy_control();
client().async_set_enable_global_privacy_control(page_id(), global_privacy_control == GlobalPrivacyControl::Yes);
LibWebView: Add do-not-track setting to about:settings
2025-04-02 09:47:44 -04:00
}
LibWebView: Do not make the client bitmap shareable for screenshots Not sure what the issue is here, but it seems to cause very incorrect screenshots on macOS. In any case, it's wasted computation.
2025-05-29 13:30:45 -04:00
static ErrorOr<LexicalPath> save_screenshot(Gfx::Bitmap const* bitmap)
LibWebView+WebContent: Add a WebContent IPC to take DOM node screenshots
2023-12-06 11:51:44 -05:00
{
LibWebView: Do not make the client bitmap shareable for screenshots Not sure what the issue is here, but it seems to cause very incorrect screenshots on macOS. In any case, it's wasted computation.
2025-05-29 13:30:45 -04:00
if (!bitmap)
Everywhere: Convert from_string_view -> from_string_literal where static
2024-09-05 15:06:15 +04:00
return Error::from_string_literal("Failed to take a screenshot");
LibWebView+WebContent: Add a WebContent IPC to take DOM node screenshots
2023-12-06 11:51:44 -05:00
Everywhere: Replace DateTime::to_string() with UnixDateTime::to_string() Replace LibCore::DateTime::to_string() with AK::UnixDateTime::to_string(). Remove unncessary #include <LibCore/DateTime.h>.
2025-06-19 21:05:42 +02:00
auto file = AK::UnixDateTime::now().to_byte_string("screenshot-%Y-%m-%d-%H-%M-%S.png"sv);
LibWebView: Use the download directory facility for saving files
2024-08-28 15:32:50 -04:00
auto path = TRY(Application::the().path_for_downloaded_file(file));
LibWebView+WebContent: Add a WebContent IPC to take DOM node screenshots
2023-12-06 11:51:44 -05:00
LibWebView: Do not make the client bitmap shareable for screenshots Not sure what the issue is here, but it seems to cause very incorrect screenshots on macOS. In any case, it's wasted computation.
2025-05-29 13:30:45 -04:00
auto encoded = TRY(Gfx::PNGWriter::encode(*bitmap));
LibWebView+WebContent: Add a WebContent IPC to take DOM node screenshots
2023-12-06 11:51:44 -05:00
LibJS+LibWebView+WebContent+Ladybird: Output GC-graph into a file Instead of displaying a massive JSON in stdout, it's more practical to save the GC-graph to a file.
2023-12-12 13:25:06 +01:00
auto dump_file = TRY(Core::File::open(path.string(), Core::File::OpenMode::Write));
TRY(dump_file->write_until_depleted(encoded));
LibWebView+WebContent: Add a WebContent IPC to take DOM node screenshots
2023-12-06 11:51:44 -05:00
LibWebView: Log the result of taking screenshots to Inspector's console It probably isn't obvious that screenshots are saved to the user's Downloads folder, so add a console message to inform them.
2023-12-09 16:57:57 -05:00
return path;
LibWebView+WebContent: Add a WebContent IPC to take DOM node screenshots
2023-12-06 11:51:44 -05:00
}
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
NonnullRefPtr<Core::Promise<LexicalPath>> ViewImplementation::take_screenshot(ScreenshotType type)
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
{
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
auto promise = Core::Promise<LexicalPath>::construct();
if (m_pending_screenshot) {
LibWeb: Fix typos - act II
2025-04-07 10:46:22 +00:00
// For simplicity, only allow taking one screenshot at a time for now. Revisit if we need
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
// to allow spamming screenshot requests for some reason.
promise->reject(Error::from_string_literal("A screenshot request is already in progress"));
return promise;
}
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
switch (type) {
case ScreenshotType::Visible:
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
if (auto* visible_bitmap = m_client_state.has_usable_bitmap ? m_client_state.front_bitmap.bitmap.ptr() : m_backup_bitmap.ptr()) {
LibWebView: Do not make the client bitmap shareable for screenshots Not sure what the issue is here, but it seems to cause very incorrect screenshots on macOS. In any case, it's wasted computation.
2025-05-29 13:30:45 -04:00
if (auto result = save_screenshot(visible_bitmap); result.is_error())
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
promise->reject(result.release_error());
else
promise->resolve(result.release_value());
}
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
break;
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
case ScreenshotType::Full:
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
m_pending_screenshot = promise;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_take_document_screenshot(page_id());
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
break;
}
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
return promise;
}
LibWeb: Make DOM Node unique IDs strongly typed (and 64 bit) This is strictly nicer than passing them around as i32 everywhere, and by switching to i64 as the underlying type, ID allocation becomes as simple as incrementing an integer.
2024-10-20 10:37:44 +02:00
NonnullRefPtr<Core::Promise<LexicalPath>> ViewImplementation::take_dom_node_screenshot(Web::UniqueNodeID node_id)
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
{
auto promise = Core::Promise<LexicalPath>::construct();
if (m_pending_screenshot) {
LibWeb: Fix typos - act II
2025-04-07 10:46:22 +00:00
// For simplicity, only allow taking one screenshot at a time for now. Revisit if we need
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
// to allow spamming screenshot requests for some reason.
promise->reject(Error::from_string_literal("A screenshot request is already in progress"));
return promise;
}
m_pending_screenshot = promise;
Ladybird+WebContent: Update IPC calls to handle multiple traversables The IPC layer between chromes and LibWeb now understands that multiple top level traversables can live in each WebContent process. This largely mechanical change adds a billion page_id/page_index arguments to make sure that pages that end up opening new WebViews through mechanisms like window.open() still work properly with those extra windows.
2024-02-02 18:00:48 -07:00
client().async_take_dom_node_screenshot(page_id(), node_id);
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
return promise;
LibWebView+WebContent: Add a WebContent IPC to take DOM node screenshots
2023-12-06 11:51:44 -05:00
}
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
void ViewImplementation::did_receive_screenshot(Badge<WebContentClient>, Gfx::ShareableBitmap const& screenshot)
LibWebView+WebContent: Add a WebContent IPC to take DOM node screenshots
2023-12-06 11:51:44 -05:00
{
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
VERIFY(m_pending_screenshot);
LibWebView: Do not make the client bitmap shareable for screenshots Not sure what the issue is here, but it seems to cause very incorrect screenshots on macOS. In any case, it's wasted computation.
2025-05-29 13:30:45 -04:00
if (auto result = save_screenshot(screenshot.bitmap()); result.is_error())
Ladybird+LibWebView+WebContent: Make the screenshot IPCs async These IPCs are different than other IPCs in that we can't just set up a callback function to be invoked when WebContent sends us the screenshot data. There are multiple places that would set that callback, and they would step on each other's toes. Instead, the screenshot APIs on ViewImplementation now return a Promise which callers can interact with to receive the screenshot (or an error).
2023-12-31 09:51:02 -05:00
m_pending_screenshot->reject(result.release_error());
else
m_pending_screenshot->resolve(result.release_value());
m_pending_screenshot = nullptr;
Browser+Ladybird+LibWebView: Move some common functions to LibWebView The implementations of handle_web_content_process_crash and take_screenshot are exactly the same across Browser and Ladybird. Let's reduce some code duplication and move them to LibWebView.
2023-05-17 09:53:13 -04:00
}
LibWebView+WebContent+headless-browser: Make the page info IPCs async The IPCs to request a page's text, layout tree, etc. are currently all synchronous. This can result in a deadlock when WebContent also makes a synchronous IPC call, as both ends will be waiting on each other. This replaces the page info IPCs with a single, asynchronous IPC. This new IPC is promise-based, much like our screenshot IPC.
2024-09-19 10:40:00 -04:00
NonnullRefPtr<Core::Promise<String>> ViewImplementation::request_internal_page_info(PageInfoType type)
{
auto promise = Core::Promise<String>::construct();
if (m_pending_info_request) {
LibWeb: Fix typos - act II
2025-04-07 10:46:22 +00:00
// For simplicity, only allow one info request at a time for now.
LibWebView+WebContent+headless-browser: Make the page info IPCs async The IPCs to request a page's text, layout tree, etc. are currently all synchronous. This can result in a deadlock when WebContent also makes a synchronous IPC call, as both ends will be waiting on each other. This replaces the page info IPCs with a single, asynchronous IPC. This new IPC is promise-based, much like our screenshot IPC.
2024-09-19 10:40:00 -04:00
promise->reject(Error::from_string_literal("A page info request is already in progress"));
return promise;
}
m_pending_info_request = promise;
client().async_request_internal_page_info(page_id(), type);
return promise;
}
void ViewImplementation::did_receive_internal_page_info(Badge<WebContentClient>, PageInfoType, String const& info)
{
VERIFY(m_pending_info_request);
m_pending_info_request->resolve(String { info });
m_pending_info_request = nullptr;
}
LibJS+LibWebView+WebContent+Ladybird: Output GC-graph into a file Instead of displaying a massive JSON in stdout, it's more practical to save the GC-graph to a file.
2023-12-12 13:25:06 +01:00
ErrorOr<LexicalPath> ViewImplementation::dump_gc_graph()
{
LibWebView+WebContent+headless-browser: Make the page info IPCs async The IPCs to request a page's text, layout tree, etc. are currently all synchronous. This can result in a deadlock when WebContent also makes a synchronous IPC call, as both ends will be waiting on each other. This replaces the page info IPCs with a single, asynchronous IPC. This new IPC is promise-based, much like our screenshot IPC.
2024-09-19 10:40:00 -04:00
auto promise = request_internal_page_info(PageInfoType::GCGraph);
auto gc_graph_json = TRY(promise->await());
LibJS+LibWebView+WebContent+Ladybird: Output GC-graph into a file Instead of displaying a massive JSON in stdout, it's more practical to save the GC-graph to a file.
2023-12-12 13:25:06 +01:00
LexicalPath path { Core::StandardPaths::tempfile_directory() };
Everywhere: Replace DateTime::to_string() with UnixDateTime::to_string() Replace LibCore::DateTime::to_string() with AK::UnixDateTime::to_string(). Remove unncessary #include <LibCore/DateTime.h>.
2025-06-19 21:05:42 +02:00
path = path.append(TRY(AK::UnixDateTime::now().to_string("gc-graph-%Y-%m-%d-%H-%M-%S.json"sv)));
LibJS+LibWebView+WebContent+Ladybird: Output GC-graph into a file Instead of displaying a massive JSON in stdout, it's more practical to save the GC-graph to a file.
2023-12-12 13:25:06 +01:00
LibWebView+WebContent+headless-browser: Make the page info IPCs async The IPCs to request a page's text, layout tree, etc. are currently all synchronous. This can result in a deadlock when WebContent also makes a synchronous IPC call, as both ends will be waiting on each other. This replaces the page info IPCs with a single, asynchronous IPC. This new IPC is promise-based, much like our screenshot IPC.
2024-09-19 10:40:00 -04:00
auto dump_file = TRY(Core::File::open(path.string(), Core::File::OpenMode::Write));
TRY(dump_file->write_until_depleted(gc_graph_json.bytes()));
LibJS+LibWebView+WebContent+Ladybird: Output GC-graph into a file Instead of displaying a massive JSON in stdout, it's more practical to save the GC-graph to a file.
2023-12-12 13:25:06 +01:00
return path;
}
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
void ViewImplementation::set_user_style_sheet(String const& source)
LibWebView: Allow using native/user style sheets on Lagom Move the methods to set the native/user style sheets to the base ViewImplementation class. We must also generate the native style sheet explicitly for now, as LibWebView on Lagom isn't able to include the main LibWebView CMakeLists.txt file yet.
2023-08-26 13:34:59 -04:00
{
LibDevTools+LibWebView: Take advantage of IPC encoding improvements
2025-03-08 11:00:03 -05:00
client().async_set_user_style(page_id(), source);
LibWebView: Allow using native/user style sheets on Lagom Move the methods to set the native/user style sheets to the base ViewImplementation class. We must also generate the native style sheet explicitly for now, as LibWebView on Lagom isn't able to include the main LibWebView CMakeLists.txt file yet.
2023-08-26 13:34:59 -04:00
}
void ViewImplementation::use_native_user_style_sheet()
{
Meta: Make embed_as_string_view.py produce Strings instead This is only used for CSS style sheets. One case wants it as a String, and the others don't care, but will in future also want to have the source as a String.
2024-08-22 12:42:12 +01:00
extern String native_stylesheet_source;
set_user_style_sheet(native_stylesheet_source);
LibWebView: Allow using native/user style sheets on Lagom Move the methods to set the native/user style sheets to the base ViewImplementation class. We must also generate the native style sheet explicitly for now, as LibWebView on Lagom isn't able to include the main LibWebView CMakeLists.txt file yet.
2023-08-26 13:34:59 -04:00
}
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
void ViewImplementation::initialize_context_menus()
{
auto& application = Application::the();
m_navigate_back_action = Action::create("Go Back"sv, ActionID::NavigateBack, [this]() {
traverse_the_history_by_delta(-1);
});
m_navigate_forward_action = Action::create("Go Forward"sv, ActionID::NavigateForward, [this]() {
traverse_the_history_by_delta(+1);
});
m_navigate_back_action->set_enabled(false);
m_navigate_forward_action->set_enabled(false);
LibWebView+UI: Generate the zoom menu
2025-09-10 07:23:15 -04:00
m_reset_zoom_action = Action::create("100%"sv, ActionID::ResetZoomViaToolbar, [this]() {
reset_zoom();
});
m_reset_zoom_action->set_tooltip("Reset zoom level"sv);
m_reset_zoom_action->set_visible(false);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
m_search_selected_text_action = Action::create("Search Selected Text"sv, ActionID::SearchSelectedText, [this]() {
auto const& search_engine = Application::settings().search_engine();
if (!search_engine.has_value())
return;
auto url_string = search_engine->format_search_query_for_navigation(*m_search_text);
auto url = URL::Parser::basic_parse(url_string);
VERIFY(url.has_value());
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 09:08:24 -04:00
Application::the().open_url_in_new_tab(*url, Web::HTML::ActivateTab::Yes);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
});
m_search_selected_text_action->set_visible(false);
auto take_and_save_screenshot = [this](auto type) {
take_screenshot(type)
->when_resolved([](auto const& path) {
Application::the().display_download_confirmation_dialog("Screenshot"sv, path);
})
.when_rejected([](auto const& error) {
if (error.is_errno() && error.code() == ECANCELED)
return;
auto error_message = MUST(String::formatted("{}", error));
Application::the().display_error_dialog(error_message);
});
};
m_take_visible_screenshot_action = Action::create("Take Visible Screenshot"sv, ActionID::TakeVisibleScreenshot, [take_and_save_screenshot]() {
take_and_save_screenshot(ScreenshotType::Visible);
});
m_take_full_screenshot_action = Action::create("Take Full Screenshot"sv, ActionID::TakeFullScreenshot, [take_and_save_screenshot]() {
take_and_save_screenshot(ScreenshotType::Full);
});
m_open_in_new_tab_action = Action::create("Open in New Tab"sv, ActionID::OpenInNewTab, [this]() {
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 09:08:24 -04:00
Application::the().open_url_in_new_tab(m_context_menu_url, Web::HTML::ActivateTab::No);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
});
m_copy_url_action = Action::create("Copy URL"sv, ActionID::CopyURL, [this]() {
LibWebView+UI: Move clipboard handling from the WebView to the App Clipboard handling largely has nothing to do with the individual web views. Rather, we interact with the system clipboard at the application level. So let's move these implementations to the Application.
2025-09-18 08:16:36 -04:00
Application::the().insert_clipboard_entry({ url_text_to_copy(m_context_menu_url), "text/plain"_string });
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
});
m_open_image_action = Action::create("Open Image"sv, ActionID::OpenImage, [this]() {
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 09:08:24 -04:00
load(m_context_menu_url);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
});
m_copy_image_action = Action::create("Copy Image"sv, ActionID::CopyImage, [this]() {
if (!m_image_context_menu_bitmap.has_value())
return;
auto bitmap = m_image_context_menu_bitmap.release_value();
if (!bitmap.is_valid())
return;
auto encoded = Gfx::PNGWriter::encode(*bitmap.bitmap());
if (encoded.is_error())
return;
LibWebView+UI: Move clipboard handling from the WebView to the App Clipboard handling largely has nothing to do with the individual web views. Rather, we interact with the system clipboard at the application level. So let's move these implementations to the Application.
2025-09-18 08:16:36 -04:00
Application::the().insert_clipboard_entry({ ByteString { encoded.value().bytes() }, "image/png"_string });
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
});
m_open_audio_action = Action::create("Open Audio"sv, ActionID::OpenAudio, [this]() {
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 09:08:24 -04:00
load(m_context_menu_url);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
});
m_open_video_action = Action::create("Open Video"sv, ActionID::OpenVideo, [this]() {
LibWebView+UI: Add an Application method to open a URL in a new tab This lets us avoid each UI needing to handle link clicks directly, and lets actions stored in LibWebView avoid awkwardly going through the link click callbacks to open URLs.
2025-09-13 09:08:24 -04:00
load(m_context_menu_url);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
});
m_media_play_action = Action::create("Play"sv, ActionID::PlayMedia, [this]() {
client().async_toggle_media_play_state(page_id());
});
m_media_pause_action = Action::create("Pause"sv, ActionID::PauseMedia, [this]() {
client().async_toggle_media_play_state(page_id());
});
m_media_mute_action = Action::create("Mute"sv, ActionID::MuteMedia, [this]() {
client().async_toggle_media_mute_state(page_id());
});
m_media_unmute_action = Action::create("Unmute"sv, ActionID::UnmuteMedia, [this]() {
client().async_toggle_media_mute_state(page_id());
});
LibWebView+UI/AppKit: Display icons in the macOS UI on Tahoe On macOS Tahoe, it is now recommended to show menu item icons. We use system symbols for this now. Symbols do not have constant variable names and must be found via the SF Symbols app. The symbols chosen here were to match Safari as close as possible.
2025-09-16 12:55:37 -04:00
m_media_show_controls_action = Action::create("Show Controls"sv, ActionID::ShowControls, [this]() {
client().async_toggle_media_controls_state(page_id());
});
m_media_hide_controls_action = Action::create("Hide Controls"sv, ActionID::HideControls, [this]() {
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
client().async_toggle_media_controls_state(page_id());
});
m_media_loop_action = Action::create_checkable("Loop"sv, ActionID::ToggleMediaLoopState, [this]() {
client().async_toggle_media_loop_state(page_id());
});
m_page_context_menu = Menu::create("Page Context Menu"sv);
m_page_context_menu->add_action(*m_navigate_back_action);
m_page_context_menu->add_action(*m_navigate_forward_action);
m_page_context_menu->add_action(application.reload_action());
m_page_context_menu->add_separator();
m_page_context_menu->add_action(application.copy_selection_action());
m_page_context_menu->add_action(application.paste_action());
m_page_context_menu->add_action(application.select_all_action());
m_page_context_menu->add_separator();
m_page_context_menu->add_action(*m_search_selected_text_action);
m_page_context_menu->add_separator();
m_page_context_menu->add_action(*m_take_visible_screenshot_action);
m_page_context_menu->add_action(*m_take_full_screenshot_action);
m_page_context_menu->add_separator();
m_page_context_menu->add_action(application.view_source_action());
m_link_context_menu = Menu::create("Link Context Menu"sv);
m_link_context_menu->add_action(*m_open_in_new_tab_action);
m_link_context_menu->add_action(*m_copy_url_action);
m_image_context_menu = Menu::create("Image Context Menu"sv);
m_image_context_menu->add_action(*m_open_image_action);
m_image_context_menu->add_action(*m_open_in_new_tab_action);
m_image_context_menu->add_separator();
m_image_context_menu->add_action(*m_copy_image_action);
m_image_context_menu->add_action(*m_copy_url_action);
m_media_context_menu = Menu::create("Media Context Menu"sv);
m_media_context_menu->add_action(*m_media_play_action);
m_media_context_menu->add_action(*m_media_pause_action);
m_media_context_menu->add_action(*m_media_mute_action);
m_media_context_menu->add_action(*m_media_unmute_action);
LibWebView+UI/AppKit: Display icons in the macOS UI on Tahoe On macOS Tahoe, it is now recommended to show menu item icons. We use system symbols for this now. Symbols do not have constant variable names and must be found via the SF Symbols app. The symbols chosen here were to match Safari as close as possible.
2025-09-16 12:55:37 -04:00
m_media_context_menu->add_action(*m_media_show_controls_action);
m_media_context_menu->add_action(*m_media_hide_controls_action);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
m_media_context_menu->add_action(*m_media_loop_action);
m_media_context_menu->add_separator();
m_media_context_menu->add_action(*m_open_audio_action);
m_media_context_menu->add_action(*m_open_video_action);
m_media_context_menu->add_action(*m_open_in_new_tab_action);
m_media_context_menu->add_separator();
m_media_context_menu->add_action(*m_copy_url_action);
}
void ViewImplementation::did_request_page_context_menu(Badge<WebContentClient>, Gfx::IntPoint content_position)
{
auto const& search_engine = Application::settings().search_engine();
auto selected_text = search_engine.has_value() ? selected_text_with_whitespace_collapsed() : OptionalNone {};
TemporaryChange change_url { m_search_text, move(selected_text) };
if (m_search_text.has_value()) {
m_search_selected_text_action->set_text(search_engine->format_search_query_for_display(*m_search_text));
m_search_selected_text_action->set_visible(true);
} else {
m_search_selected_text_action->set_visible(false);
}
if (m_page_context_menu->on_activation)
m_page_context_menu->on_activation(to_widget_position(content_position));
}
void ViewImplementation::did_request_link_context_menu(Badge<WebContentClient>, Gfx::IntPoint content_position, URL::URL url)
{
m_context_menu_url = move(url);
m_open_in_new_tab_action->set_text("Open in New Tab"sv);
switch (url_type(m_context_menu_url)) {
case URLType::Email:
m_copy_url_action->set_text("Copy Email Address"sv);
break;
case URLType::Telephone:
m_copy_url_action->set_text("Copy Phone Number"sv);
break;
case URLType::Other:
m_copy_url_action->set_text("Copy Link Address"sv);
break;
}
if (m_link_context_menu->on_activation)
m_link_context_menu->on_activation(to_widget_position(content_position));
}
void ViewImplementation::did_request_image_context_menu(Badge<WebContentClient>, Gfx::IntPoint content_position, URL::URL url, Optional<Gfx::ShareableBitmap> bitmap)
{
m_context_menu_url = move(url);
m_image_context_menu_bitmap = move(bitmap);
m_open_in_new_tab_action->set_text("Open Image in New Tab"sv);
m_copy_url_action->set_text("Copy Image URL"sv);
m_copy_image_action->set_enabled(m_image_context_menu_bitmap.has_value());
if (m_image_context_menu->on_activation)
m_image_context_menu->on_activation(to_widget_position(content_position));
}
void ViewImplementation::did_request_media_context_menu(Badge<WebContentClient>, Gfx::IntPoint content_position, Web::Page::MediaContextMenu menu)
{
m_context_menu_url = move(menu.media_url);
m_open_in_new_tab_action->set_text(menu.is_video ? "Open Video in New Tab"sv : "Open Audio in new Tab"sv);
m_copy_url_action->set_text(menu.is_video ? "Copy Video URL"sv : "Copy Audio URL"sv);
m_open_audio_action->set_visible(!menu.is_video);
m_open_video_action->set_visible(menu.is_video);
m_media_play_action->set_visible(!menu.is_playing);
m_media_pause_action->set_visible(menu.is_playing);
m_media_mute_action->set_visible(!menu.is_muted);
m_media_unmute_action->set_visible(menu.is_muted);
LibWebView+UI/AppKit: Display icons in the macOS UI on Tahoe On macOS Tahoe, it is now recommended to show menu item icons. We use system symbols for this now. Symbols do not have constant variable names and must be found via the SF Symbols app. The symbols chosen here were to match Safari as close as possible.
2025-09-16 12:55:37 -04:00
m_media_show_controls_action->set_visible(!menu.has_user_agent_controls);
m_media_hide_controls_action->set_visible(menu.has_user_agent_controls);
LibWebView+UI: Generate application context menus This migrates all duplicated context menus from the UIs to LibWebView. The context menu actions are now largely handled directly in LibWebView, with some UI-specific callbacks added to display e.g. confirmation dialogs. Actions that only ever apply to a specific web view are stored on the ViewImplementation itself. Actions that need to be dynamically applied to the active web view are stored on the Application.
2025-09-01 08:20:14 -04:00
m_media_loop_action->set_checked(menu.is_looping);
if (m_media_context_menu->on_activation)
m_media_context_menu->on_activation(to_widget_position(content_position));
}
LibWebView+Ladybird: Begin de-duplicate WebView implementations This starts moving code equally shared between the OOPWV and Ladybird WebContentView implementations to WebView::ViewImplementation, beginning with the client state.
2023-01-12 19:27:17 +00:00
}
Reference in a new issue Copy permalink