Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-20 08:03:21 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Services/WebDriver/WebContentConnection.cpp

66 lines
1.6 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 10:18:11 -05: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 09:40:17 -04: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 10:18:11 -05: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 11:00:31 -05: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 10:18:11 -05: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 15:47:33 -06: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 10:18:11 -05: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 14: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 10:18:11 -05:00
}
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 10:28:29 -04:00
void WebContentConnection::navigation_complete(Web::WebDriver::Response const& response)
{
if (on_navigation_complete)
on_navigation_complete(response);
}
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 WebContentConnection::window_rect_updated(Web::WebDriver::Response const& response)
{
if (on_window_rect_updated)
on_window_rect_updated(response);
}
WebContent+WebDriver: Make the element locator endpoints asynchronous We currently spin the event loop to wait for the specified element to become available. As we've seen with other endpoints, this can result in dead locks if another web component also spins the event loop. This patch makes the locator implementations asynchronous.
2024-10-30 15:26:04 -04:00
void WebContentConnection::find_elements_complete(Web::WebDriver::Response const& response)
{
if (on_find_elements_complete)
on_find_elements_complete(response);
}
WebDriver: Handle script execution results without spinning event loops We currently spin the platform event loop while awaiting scripts to complete. This causes WebContent to hang if another component is also spinning the event loop. The particular example that instigated this patch was the navigable's navigation loop (which spins until the fetch process is complete), triggered by a form submission to an iframe. So instead of spinning, we now return immediately from the script executors, after setting up listeners for either the script's promise to be resolved or for a timeout. The HTTP request to WebDriver must finish synchronously though, so now the WebDriver process spins its event loop until WebContent signals that the script completed. This should be ok - the WebDriver process isn't expected to be doing anything else in the meantime. Also, as a consequence of these changes, we now actually handle time outs. We were previously creating the timeout timer, but not starting it.
2024-09-13 07:42:24 -04:00
void WebContentConnection::script_executed(Web::WebDriver::Response const& response)
{
if (on_script_executed)
on_script_executed(response);
}
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 09:40:17 -04:00
void WebContentConnection::actions_performed(Web::WebDriver::Response const& response)
{
if (on_actions_performed)
on_actions_performed(response);
}
LibWeb+WebContent+WebDriver: Asynchronously wait for dialog dismissal There was a timing issue here where WebDriver would dismiss a dialog, and then invoke another endpoint before the dialog was actually closed. This is because the dismissal first has to hop over to the UI process to close the graphical dialog, which then asynchronously informs WebContent of the result. It's not until WebContent receives that result that the dialog is considered closed, thus those subsequent endpoints would abort due a dialog being "open". We now wait for dialogs to be fully closed before returning from the dismissal endpoints.
2024-10-25 12:31:07 -04:00
void WebContentConnection::dialog_closed(Web::WebDriver::Response const& response)
{
if (on_dialog_closed)
on_dialog_closed(response);
}
LibWeb+WebContent+WebDriver: Make the screenshot endpoints asynchronous These were the last WebDriver endpoints spinning the event loop.
2024-10-30 20:29:26 -04:00
void WebContentConnection::screenshot_taken(Web::WebDriver::Response const& response)
{
if (on_screenshot_taken)
on_screenshot_taken(response);
}
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 10:18:11 -05:00
}
Reference in a new issue Copy permalink