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

30 lines
660 B
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 {
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
WebContentConnection::WebContentConnection(IPC::Transport transport)
: 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
}
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
void WebContentConnection::driver_execution_complete(Web::WebDriver::Response const& 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)
on_driver_execution_complete(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
}
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