Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 21:30:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibWeb/WebDriver/ExecuteScript.h

30 lines
967 B
C
Raw Normal View History

LibWeb+WebContent: Add WebDriver infrastructure for executing scripts This cannot be done on the Browser or WebDriver ends, or via the existing run_javascript() IPC endpoint, as we cannot transfer JS objects through the IPC boundary (yet), only serialized JSON, so the individual WebDriver steps around script execution need to run in the WebContent process.
2022-11-02 18:02:19 +00:00
/*
LibWeb/WebDriver: Handle WindowProxy in internal_json_clone_algorithm() To test: ```console curl http://0.0.0.0:8000/session \ -H 'Content-Type: application/json' \ -d '{"capabilities": {}}' curl http://0.0.0.0:8000/session/0/execute/sync \ -H 'Content-Type: application/json' \ -d '{"script": "return window;", "args": []}' ``` Which should result in: ```json { "value": { "window-fcc6-11e5-b4f8-330a88ab9d7f": "86307df6-e2f1-4175-85cb-77295ff90898" } } ```
2023-04-20 17:41:32 +01:00
* Copyright (c) 2022-2023, Linus Groh <linusg@serenityos.org>
LibWeb+WebContent: Simplify hand-rolled script execution result struct Instead of maintaining a list of script execution result types, which we then map to WebDriver error types, just return the WebDriver error that is specified by the spec. Then perform the JSON clone algorithm from the caller in WebDriverConnection, again as specified by the spec. To do so, this moves the JSON clone algorithm to its own file. This will also be the future home of the JSON deserialize algorithm, which will need some of the internal AOs implemented there.
2024-11-02 14:29:37 -04:00
* Copyright (c) 2024, Tim Flynn <trflynn89@ladybird.org>
LibWeb+WebContent: Add WebDriver infrastructure for executing scripts This cannot be done on the Browser or WebDriver ends, or via the existing run_javascript() IPC endpoint, as we cannot transfer JS objects through the IPC boundary (yet), only serialized JSON, so the individual WebDriver steps around script execution need to run in the WebContent process.
2022-11-02 18:02:19 +00:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Forward.h>
#include <LibJS/Forward.h>
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
#include <LibJS/Heap/HeapFunction.h>
LibWeb+WebContent: Simplify hand-rolled script execution result struct Instead of maintaining a list of script execution result types, which we then map to WebDriver error types, just return the WebDriver error that is specified by the spec. Then perform the JSON clone algorithm from the caller in WebDriverConnection, again as specified by the spec. To do so, this moves the JSON clone algorithm to its own file. This will also be the future home of the JSON deserialize algorithm, which will need some of the internal AOs implemented there.
2024-11-02 14:29:37 -04:00
#include <LibJS/Runtime/Promise.h>
LibWeb+WebContent: Add WebDriver infrastructure for executing scripts This cannot be done on the Browser or WebDriver ends, or via the existing run_javascript() IPC endpoint, as we cannot transfer JS objects through the IPC boundary (yet), only serialized JSON, so the individual WebDriver steps around script execution need to run in the WebContent process.
2022-11-02 18:02:19 +00:00
#include <LibJS/Runtime/Value.h>
#include <LibWeb/Forward.h>
namespace Web::WebDriver {
LibWeb+WebContent: Simplify hand-rolled script execution result struct Instead of maintaining a list of script execution result types, which we then map to WebDriver error types, just return the WebDriver error that is specified by the spec. Then perform the JSON clone algorithm from the caller in WebDriverConnection, again as specified by the spec. To do so, this moves the JSON clone algorithm to its own file. This will also be the future home of the JSON deserialize algorithm, which will need some of the internal AOs implemented there.
2024-11-02 14:29:37 -04:00
struct ExecutionResult {
JS::Promise::State state { JS::Promise::State::Pending };
JS::Value value {};
LibWeb+WebContent: Add WebDriver infrastructure for executing scripts This cannot be done on the Browser or WebDriver ends, or via the existing run_javascript() IPC endpoint, as we cannot transfer JS objects through the IPC boundary (yet), only serialized JSON, so the individual WebDriver steps around script execution need to run in the WebContent process.
2022-11-02 18:02:19 +00:00
};
LibWeb+WebContent: Simplify hand-rolled script execution result struct Instead of maintaining a list of script execution result types, which we then map to WebDriver error types, just return the WebDriver error that is specified by the spec. Then perform the JSON clone algorithm from the caller in WebDriverConnection, again as specified by the spec. To do so, this moves the JSON clone algorithm to its own file. This will also be the future home of the JSON deserialize algorithm, which will need some of the internal AOs implemented there.
2024-11-02 14:29:37 -04:00
using OnScriptComplete = JS::HeapFunction<void(ExecutionResult)>;
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
LibWeb+WebContent: Use the current window to execute WebDriver scripts Rather than using the page's top-level window, we must use the window that is currently active in the WebDriver session.
2024-09-14 08:04:15 -04:00
void execute_script(HTML::BrowsingContext const&, ByteString body, JS::MarkedVector<JS::Value> arguments, Optional<u64> const& timeout_ms, JS::NonnullGCPtr<OnScriptComplete> on_complete);
void execute_async_script(HTML::BrowsingContext const&, ByteString body, JS::MarkedVector<JS::Value> arguments, Optional<u64> const& timeout_ms, JS::NonnullGCPtr<OnScriptComplete> on_complete);
LibWeb+WebContent: Add WebDriver infrastructure for executing scripts This cannot be done on the Browser or WebDriver ends, or via the existing run_javascript() IPC endpoint, as we cannot transfer JS objects through the IPC boundary (yet), only serialized JSON, so the individual WebDriver steps around script execution need to run in the WebContent process.
2022-11-02 18:02:19 +00:00
}
Reference in a new issue Copy permalink