dmaax/ladybird
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
ladybird/Libraries/LibWeb/WebDriver/ExecuteScript.h

32 lines
990 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 15:02:19 -03: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 13:41:32 -03: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 15:29:37 -03: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 15:02:19 -03:00
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
#include <AK/Forward.h>
LibWeb+WebContent+WebDriver: Port WebDriver to String
2025-02-17 15:58:21 -03:00
#include <AK/String.h>
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
#include <LibGC/Function.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 15:02:19 -03:00
#include <LibJS/Forward.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 15:29:37 -03: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 15:02:19 -03:00
#include <LibJS/Runtime/Value.h>
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 23:35:33 -03:00
#include <LibWeb/Export.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 15:02:19 -03:00
#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 15:29:37 -03: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 15:02:19 -03:00
};
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-14 12:01:23 -03:00
using OnScriptComplete = GC::Function<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 08:42:24 -03:00
LibWeb: Enable EXPLICIT_SYMBOL_EXPORT
2025-07-19 23:35:33 -03:00
WEB_API void execute_script(HTML::BrowsingContext const&, String body, GC::RootVector<JS::Value> arguments, Optional<u64> const& timeout_ms, GC::Ref<OnScriptComplete> on_complete);
WEB_API void execute_async_script(HTML::BrowsingContext const&, String body, GC::RootVector<JS::Value> arguments, Optional<u64> const& timeout_ms, GC::Ref<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 15:02:19 -03:00
}
Reference in a new issue Copy permalink