dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Services/WebDriver/WebContentConnection.cpp

48 lines
1.1 KiB
C++
Raw Normal View History

Browser+LibWebView+WebDriver: Connect WebDriver to WebContent First, this moves the WebDriver socket to the /tmp/websocket/ directory, as WebDriver now creates multiple sockets per session. Those sockets are now created with Core::LocalServer rather than manually setting up the listening sockets (this was an existing FIXME which resolved some issues I was hitting with creating a second listening socket). WebDriver passes both socket paths to Browser via command line. Browser continues to connect itself via one socket path, then forwards the other socket path to the WebContent process created by the OOPWV. WebContent then connects to WebDriver over this path. WebContent will temporarily set the navigator.webdriver flag to true after connecting to WebDriver. This will soon be moved to its own IPC to be sent by WebDriver.
2022-11-08 12:18:11 -03:00
/*
LibWeb+WebContent+WebDriver: Implement the Perform Actions endpoint Similar to script execution, this spins the WebDriver process until the action is complete (rather than spinning the WebContent process, which we've seen result in deadlocks).
2024-09-29 10:40:17 -03:00
* Copyright (c) 2022-2024, Tim Flynn <trflynn89@ladybird.org>
Browser+LibWebView+WebDriver: Connect WebDriver to WebContent First, this moves the WebDriver socket to the /tmp/websocket/ directory, as WebDriver now creates multiple sockets per session. Those sockets are now created with Core::LocalServer rather than manually setting up the listening sockets (this was an existing FIXME which resolved some issues I was hitting with creating a second listening socket). WebDriver passes both socket paths to Browser via command line. Browser continues to connect itself via one socket path, then forwards the other socket path to the WebContent process created by the OOPWV. WebContent then connects to WebDriver over this path. WebContent will temporarily set the navigator.webdriver flag to true after connecting to WebDriver. This will soon be moved to its own IPC to be sent by WebDriver.
2022-11-08 12:18:11 -03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
WebDriver: Remove "Services/" prefix from local WebDriver includes This is to allow building some of these files from Ladybird. The Build directory for Ladybird does not include the "Services/" path.
2022-11-14 13:00:31 -03:00
#include <WebDriver/Client.h>
#include <WebDriver/WebContentConnection.h>
Browser+LibWebView+WebDriver: Connect WebDriver to WebContent First, this moves the WebDriver socket to the /tmp/websocket/ directory, as WebDriver now creates multiple sockets per session. Those sockets are now created with Core::LocalServer rather than manually setting up the listening sockets (this was an existing FIXME which resolved some issues I was hitting with creating a second listening socket). WebDriver passes both socket paths to Browser via command line. Browser continues to connect itself via one socket path, then forwards the other socket path to the WebContent process created by the OOPWV. WebContent then connects to WebDriver over this path. WebContent will temporarily set the navigator.webdriver flag to true after connecting to WebDriver. This will soon be moved to its own IPC to be sent by WebDriver.
2022-11-08 12:18:11 -03:00
namespace WebDriver {
Everywhere: Make TransportSocket non-movable Instead of wrapping all non-movable members of TransportSocket in OwnPtr to keep it movable, make TransportSocket itself non-movable and wrap it in OwnPtr.
2025-04-08 17:01:46 -03:00
WebContentConnection::WebContentConnection(NonnullOwnPtr<IPC::Transport> transport)
LibIPC+Everywhere: Introduce an IPC Transport abstraction This abstraction will help us to support multiple IPC transport mechanisms going forward. For now, we only have a TransportSocket that implements the same behavior we previously had, using Unix Sockets for IPC.
2024-10-22 18:47:33 -03:00
: IPC::ConnectionFromClient<WebDriverClientEndpoint, WebDriverServerEndpoint>(*this, move(transport), 1)
Browser+LibWebView+WebDriver: Connect WebDriver to WebContent First, this moves the WebDriver socket to the /tmp/websocket/ directory, as WebDriver now creates multiple sockets per session. Those sockets are now created with Core::LocalServer rather than manually setting up the listening sockets (this was an existing FIXME which resolved some issues I was hitting with creating a second listening socket). WebDriver passes both socket paths to Browser via command line. Browser continues to connect itself via one socket path, then forwards the other socket path to the WebContent process created by the OOPWV. WebContent then connects to WebDriver over this path. WebContent will temporarily set the navigator.webdriver flag to true after connecting to WebDriver. This will soon be moved to its own IPC to be sent by WebDriver.
2022-11-08 12:18:11 -03:00
{
}
void WebContentConnection::die()
{
WebDriver: Fix handling of disconnected WebContent process If WebContent process got disconnected it is only necessary to remove associated window instead of terminating the entire session.
2023-03-19 08:08:52 -03:00
if (on_close)
on_close();
Browser+LibWebView+WebDriver: Connect WebDriver to WebContent First, this moves the WebDriver socket to the /tmp/websocket/ directory, as WebDriver now creates multiple sockets per session. Those sockets are now created with Core::LocalServer rather than manually setting up the listening sockets (this was an existing FIXME which resolved some issues I was hitting with creating a second listening socket). WebDriver passes both socket paths to Browser via command line. Browser continues to connect itself via one socket path, then forwards the other socket path to the WebContent process created by the OOPWV. WebContent then connects to WebDriver over this path. WebContent will temporarily set the navigator.webdriver flag to true after connecting to WebDriver. This will soon be moved to its own IPC to be sent by WebDriver.
2022-11-08 12:18:11 -03:00
}
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
void WebContentConnection::driver_execution_complete(Web::WebDriver::Response response)
WebContent+WebDriver: Asynchronously wait for navigations to complete Similar to commit c2cf65adac78912883996153fb608dafe389b6e0, we should avoid spinning the event loop from the WebContent-side of the WebDriver connection. This can result in deadlocks if another component in LibWeb also spins the event loop. The AO to await navigations has two event loop spinners - waiting for the navigation to complete and for the document to reach the target readiness state. We now use NavigationObserver and DocumentObserver to be notified when these conditions are met. And we use the same async IPC mechanism as script execution to notify the WebDriver process when all conditions are met (or timed out).
2024-10-25 11:28:29 -03:00
{
WebContent+WebDriver: Consolidate driver execution completion callbacks Some WebDriver hooks will need to inform the client that execution has completed, but without any knowledge of what endpoint was running. Since there can only ever be a single WebDriver endpoint executing at once, we can replace the completion callbacks with a single callback.
2024-11-01 08:42:21 -03:00
if (on_driver_execution_complete)
LibIPC+Everywhere: Always pass ownership of transferred data to clients This has been a longstanding ergonomic issue with our IPC compiler. Non- trivial types were previously passed by const&. So if we wanted to avoid expensive copies, we would have to const_cast and move the data. We now pass ownership of all transferred data to the client subclasses. This allows us to remove const_cast from these methods, and allows us to avoid some trivial expensive copies that we didn't bother to const_cast.
2025-03-08 14:22:39 -03:00
on_driver_execution_complete(move(response));
LibWeb+WebContent+WebDriver: Make the screenshot endpoints asynchronous These were the last WebDriver endpoints spinning the event loop.
2024-10-30 21:29:26 -03:00
}
WebDriver: Send window handle asynchronously after WebContent connects This prevents a potential deadlock when tests open many popup windows in quick succession.
2026-02-11 10:46:07 -03:00
void WebContentConnection::did_set_window_handle(String handle)
{
if (on_did_set_window_handle)
on_did_set_window_handle(move(handle));
}
LibWebView: Keep browser history in the UI process Use the LibWebView history mirror to preserve traversable session history across WebContent process swaps. WebContent reports snapshots to the UI process, and new renderers can be seeded from the mirror. Browser back and forward now resolve through the UI-owned used history steps. WebContent still runs the spec traversal path when the current renderer has enough matching state to do so. Handle canceled and no-op UI navigations without leaving speculative history entries or pending WebDriver waits behind. Preserve traversal precheck state across synchronous IPC shutdown, and avoid overwriting a restored target entry's persisted scroll state before the document has adopted that entry.
2026-06-13 11:06:49 -03:00
void WebContentConnection::did_start_window_replacement(String handle)
{
if (on_did_start_window_replacement)
on_did_start_window_replacement(move(handle));
}
void WebContentConnection::did_close_window(String handle)
{
if (on_did_close_window)
on_did_close_window(move(handle));
}
Browser+LibWebView+WebDriver: Connect WebDriver to WebContent First, this moves the WebDriver socket to the /tmp/websocket/ directory, as WebDriver now creates multiple sockets per session. Those sockets are now created with Core::LocalServer rather than manually setting up the listening sockets (this was an existing FIXME which resolved some issues I was hitting with creating a second listening socket). WebDriver passes both socket paths to Browser via command line. Browser continues to connect itself via one socket path, then forwards the other socket path to the WebContent process created by the OOPWV. WebContent then connects to WebDriver over this path. WebContent will temporarily set the navigator.webdriver flag to true after connecting to WebDriver. This will soon be moved to its own IPC to be sent by WebDriver.
2022-11-08 12:18:11 -03:00
}
Reference in a new issue Copy permalink