Morph MORPH
SIGN IN SIGN UP
SeleniumHQ / selenium UNCLAIMED

A browser automation framework and ecosystem.

34170 0 116 Java
Normal View History Raw
Copyright uniformity for C++ projects Fixes copyright notices for files in the iedriver, iedriverserver, and webdriver-server, in accordance with issue #401.
2015-04-13 12:09:26 -04:00
// Licensed to the Software Freedom Conservancy (SFC) under one
// or more contributor license agreements. See the NOTICE file
// distributed with this work for additional information
// regarding copyright ownership. The SFC licenses this file
// to you under the Apache License, Version 2.0 (the "License");
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.
#ifndef WEBDRIVER_IE_SCRIPT_H_
#define WEBDRIVER_IE_SCRIPT_H_
#include <string>
Removing extra round-trips through JavaScript engine when executing script
2013-07-05 11:09:15 -04:00
#include <vector>
Cleaning up #includes in C++ code Also updating Visual Studio solution file to build correct projects in proper platform/configurations.
2014-08-19 21:11:00 +00:00
Moving implementation code of IE driver command handlers from headers The initial implementation of the IE driver's command handlers put the implementation for each command directly in the header files. While this works, it's not standard practice, and has led to a spaghetti-code of include statements. This takes the first step toward fixing that by moving the implementation of each command into a .cpp file, leaving the header to only contain the class definition.
2017-02-14 09:48:56 -08:00
#include "CustomTypes.h"
Making set window rect command spec-compliant for x and y coordinates The W3C WebDriver specification allows negative x and y coordinates for setting a window rect. Previously, the driver forced the passed in coordinates to be greater than zero.
2018-07-24 13:15:39 -07:00
#define ANONYMOUS_FUNCTION_START L"(function() { "
#define ANONYMOUS_FUNCTION_END L" })();"
Moving implementation code of IE driver command handlers from headers The initial implementation of the IE driver's command handlers put the implementation for each command directly in the header files. While this works, it's not standard practice, and has led to a spaghetti-code of include statements. This takes the first step toward fixing that by moving the implementation of each command into a .cpp file, leaving the header to only contain the class definition.
2017-02-14 09:48:56 -08:00
// Forward declaration of classes.
Cleaning up #includes in C++ code Also updating Visual Studio solution file to build correct projects in proper platform/configurations.
2014-08-19 21:11:00 +00:00
namespace Json {
class Value;
} // namespace Json
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
namespace webdriver {
Making JavaScript execution asynchronous for executeScript in IE Prior to this change, the execution of JavaScript via the executeScript method was synchronous. This would mean that if the script passed into the driver called the JavaScript `alert()`, `confirm()`, or `prompt()` functions, the WebDriver code would hang until the dialog was manually dismissed. Moving this to asynchronous execution allows the driver to be compliant with the W3C WebDriver Specification, that mandates that user prompts triggered by executeScript should be able to be handled by the WebDriver alert handling functions. However, this spec compliance comes at several costs. The first cost is complexity. The IE driver uses COM interfaces to communicate with Internet Explorer. COM is inherently single-threaded, and requires a fair amount of manipulation to allow accessing the objects on separate threads. This leads to requiring a fairly complex system of communication and synchronization between the threads to give the illusion of a synchronous script execution. The second cost is performance. Because of the need for synchronization, this change **may** introduce a performance hit in the IE driver. This is unfortunate, but unavoidable. The benefit of having user-initiated JavaScript not block and hang WebDriver code far outweighs whatever relatively small performance hit has been introduced.
2018-02-07 12:04:43 -08:00
struct ElementInfo {
std::string element_id;
LPSTREAM element_stream;
};
Fixing IE driver element detection for user-executed JavaScript Fixing a corner case where elements added to the known element repository via non-JavaScript means were not being properly detected when the same element was located via user-executed JavaScript. We now properly sync up the element repository once the user's JavaScript has completed.
2018-02-21 05:49:29 -08:00
struct RemappedElementInfo {
std::string original_element_id;
std::string element_id;
};
Moving implementation code of IE driver command handlers from headers The initial implementation of the IE driver's command handlers put the implementation for each command directly in the header files. While this works, it's not standard practice, and has led to a spaghetti-code of include statements. This takes the first step toward fixing that by moving the implementation of each command into a .cpp file, leaving the header to only contain the class definition.
2017-02-14 09:48:56 -08:00
// Forward declaration of classes.
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
class IECommandExecutor;
Making JavaScript execution asynchronous for executeScript in IE Prior to this change, the execution of JavaScript via the executeScript method was synchronous. This would mean that if the script passed into the driver called the JavaScript `alert()`, `confirm()`, or `prompt()` functions, the WebDriver code would hang until the dialog was manually dismissed. Moving this to asynchronous execution allows the driver to be compliant with the W3C WebDriver Specification, that mandates that user prompts triggered by executeScript should be able to be handled by the WebDriver alert handling functions. However, this spec compliance comes at several costs. The first cost is complexity. The IE driver uses COM interfaces to communicate with Internet Explorer. COM is inherently single-threaded, and requires a fair amount of manipulation to allow accessing the objects on separate threads. This leads to requiring a fairly complex system of communication and synchronization between the threads to give the illusion of a synchronous script execution. The second cost is performance. Because of the need for synchronization, this change **may** introduce a performance hit in the IE driver. This is unfortunate, but unavoidable. The benefit of having user-initiated JavaScript not block and hang WebDriver code far outweighs whatever relatively small performance hit has been introduced.
2018-02-07 12:04:43 -08:00
class IElementManager;
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
class Script {
public:
Script(IHTMLDocument2* document,
std::string script_source,
unsigned long argument_count);
Script(IHTMLDocument2* document,
std::wstring script_source,
unsigned long argument_count);
Refactor IE user-initiated JavaScript execution to use JSON objects This IE driver refactor is internal, but should not change behavior of the driver. It is intended to let the driver's internal script executor use the direct internal JSON objects as arguments for script execution, deferring their conversion into variants until directly before execution.
2018-02-01 16:08:30 -08:00
Script(IHTMLDocument2* document,
std::string script_source);
Script(IHTMLDocument2* document,
std::wstring script_source);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
~Script(void);
std::wstring source_code() const { return this->source_code_; }
VARIANT result() { return this->result_; }
void set_result(VARIANT value) {
Simplifying object handling code in IE driver. COM objects are now correctly referenced everywhere via smart pointers, and use of some aliased types is now replaced by the C++ primitives.
2013-03-25 13:34:23 -04:00
this->result_.Copy(&value);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
}
void AddArgument(const std::string& argument);
void AddArgument(const std::wstring& argument);
void AddArgument(const int argument);
void AddArgument(const double argument);
void AddArgument(const bool argument);
void AddArgument(ElementHandle argument);
void AddArgument(IHTMLElement* argument);
void AddArgument(VARIANT argument);
void AddNullArgument(void);
Making JavaScript execution asynchronous for executeScript in IE Prior to this change, the execution of JavaScript via the executeScript method was synchronous. This would mean that if the script passed into the driver called the JavaScript `alert()`, `confirm()`, or `prompt()` functions, the WebDriver code would hang until the dialog was manually dismissed. Moving this to asynchronous execution allows the driver to be compliant with the W3C WebDriver Specification, that mandates that user prompts triggered by executeScript should be able to be handled by the WebDriver alert handling functions. However, this spec compliance comes at several costs. The first cost is complexity. The IE driver uses COM interfaces to communicate with Internet Explorer. COM is inherently single-threaded, and requires a fair amount of manipulation to allow accessing the objects on separate threads. This leads to requiring a fairly complex system of communication and synchronization between the threads to give the illusion of a synchronous script execution. The second cost is performance. Because of the need for synchronization, this change **may** introduce a performance hit in the IE driver. This is unfortunate, but unavoidable. The benefit of having user-initiated JavaScript not block and hang WebDriver code far outweighs whatever relatively small performance hit has been introduced.
2018-02-07 12:04:43 -08:00
int AddArguments(IElementManager* element_manager, const Json::Value& arguments);
Refactor IE user-initiated JavaScript execution to use JSON objects This IE driver refactor is internal, but should not change behavior of the driver. It is intended to let the driver's internal script executor use the direct internal JSON objects as arguments for script execution, deferring their conversion into variants until directly before execution.
2018-02-01 16:08:30 -08:00
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
bool ResultIsEmpty(void);
bool ResultIsString(void);
bool ResultIsInteger(void);
bool ResultIsBoolean(void);
bool ResultIsDouble(void);
bool ResultIsArray(void);
bool ResultIsObject(void);
bool ResultIsElement(void);
bool ResultIsElementCollection(void);
bool ResultIsIDispatch(void);
int Execute(void);
Adding convenience methods on internal IE driver Script object
2018-02-14 14:32:04 -08:00
int Execute(const IECommandExecutor& command_executor,
const Json::Value& args,
Json::Value* result);
int ExecuteAsync(const IECommandExecutor& command_executor,
const Json::Value& args,
HWND* async_executor_handle);
Making JavaScript execution asynchronous for executeScript in IE Prior to this change, the execution of JavaScript via the executeScript method was synchronous. This would mean that if the script passed into the driver called the JavaScript `alert()`, `confirm()`, or `prompt()` functions, the WebDriver code would hang until the dialog was manually dismissed. Moving this to asynchronous execution allows the driver to be compliant with the W3C WebDriver Specification, that mandates that user prompts triggered by executeScript should be able to be handled by the WebDriver alert handling functions. However, this spec compliance comes at several costs. The first cost is complexity. The IE driver uses COM interfaces to communicate with Internet Explorer. COM is inherently single-threaded, and requires a fair amount of manipulation to allow accessing the objects on separate threads. This leads to requiring a fairly complex system of communication and synchronization between the threads to give the illusion of a synchronous script execution. The second cost is performance. Because of the need for synchronization, this change **may** introduce a performance hit in the IE driver. This is unfortunate, but unavoidable. The benefit of having user-initiated JavaScript not block and hang WebDriver code far outweighs whatever relatively small performance hit has been introduced.
2018-02-07 12:04:43 -08:00
int ExecuteAsync(const IECommandExecutor& command_executor,
const Json::Value& args,
const int timeout_override_in_milliseconds,
HWND* async_executor_handle);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
int ConvertResultToJsonValue(const IECommandExecutor& executor,
Json::Value* value);
Making JavaScript execution asynchronous for executeScript in IE Prior to this change, the execution of JavaScript via the executeScript method was synchronous. This would mean that if the script passed into the driver called the JavaScript `alert()`, `confirm()`, or `prompt()` functions, the WebDriver code would hang until the dialog was manually dismissed. Moving this to asynchronous execution allows the driver to be compliant with the W3C WebDriver Specification, that mandates that user prompts triggered by executeScript should be able to be handled by the WebDriver alert handling functions. However, this spec compliance comes at several costs. The first cost is complexity. The IE driver uses COM interfaces to communicate with Internet Explorer. COM is inherently single-threaded, and requires a fair amount of manipulation to allow accessing the objects on separate threads. This leads to requiring a fairly complex system of communication and synchronization between the threads to give the illusion of a synchronous script execution. The second cost is performance. Because of the need for synchronization, this change **may** introduce a performance hit in the IE driver. This is unfortunate, but unavoidable. The benefit of having user-initiated JavaScript not block and hang WebDriver code far outweighs whatever relatively small performance hit has been introduced.
2018-02-07 12:04:43 -08:00
int ConvertResultToJsonValue(IElementManager* element_manager,
Refactor IE user-initiated JavaScript execution to use JSON objects This IE driver refactor is internal, but should not change behavior of the driver. It is intended to let the driver's internal script executor use the direct internal JSON objects as arguments for script execution, deferring their conversion into variants until directly before execution.
2018-02-01 16:08:30 -08:00
Json::Value* value);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
Making JavaScript execution asynchronous for executeScript in IE Prior to this change, the execution of JavaScript via the executeScript method was synchronous. This would mean that if the script passed into the driver called the JavaScript `alert()`, `confirm()`, or `prompt()` functions, the WebDriver code would hang until the dialog was manually dismissed. Moving this to asynchronous execution allows the driver to be compliant with the W3C WebDriver Specification, that mandates that user prompts triggered by executeScript should be able to be handled by the WebDriver alert handling functions. However, this spec compliance comes at several costs. The first cost is complexity. The IE driver uses COM interfaces to communicate with Internet Explorer. COM is inherently single-threaded, and requires a fair amount of manipulation to allow accessing the objects on separate threads. This leads to requiring a fairly complex system of communication and synchronization between the threads to give the illusion of a synchronous script execution. The second cost is performance. Because of the need for synchronization, this change **may** introduce a performance hit in the IE driver. This is unfortunate, but unavoidable. The benefit of having user-initiated JavaScript not block and hang WebDriver code far outweighs whatever relatively small performance hit has been introduced.
2018-02-07 12:04:43 -08:00
std::wstring polling_source_code(void) const { return this->polling_source_code_; }
void set_polling_source_code(const std::wstring& value) { this->polling_source_code_ = value; }
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
private:
bool CreateAnonymousFunction(VARIANT* result);
Making JavaScript execution asynchronous for executeScript in IE Prior to this change, the execution of JavaScript via the executeScript method was synchronous. This would mean that if the script passed into the driver called the JavaScript `alert()`, `confirm()`, or `prompt()` functions, the WebDriver code would hang until the dialog was manually dismissed. Moving this to asynchronous execution allows the driver to be compliant with the W3C WebDriver Specification, that mandates that user prompts triggered by executeScript should be able to be handled by the WebDriver alert handling functions. However, this spec compliance comes at several costs. The first cost is complexity. The IE driver uses COM interfaces to communicate with Internet Explorer. COM is inherently single-threaded, and requires a fair amount of manipulation to allow accessing the objects on separate threads. This leads to requiring a fairly complex system of communication and synchronization between the threads to give the illusion of a synchronous script execution. The second cost is performance. Because of the need for synchronization, this change **may** introduce a performance hit in the IE driver. This is unfortunate, but unavoidable. The benefit of having user-initiated JavaScript not block and hang WebDriver code far outweighs whatever relatively small performance hit has been introduced.
2018-02-07 12:04:43 -08:00
int CreateAsyncScriptExecutor(HWND element_repository_handle,
const std::wstring& serialized_args,
HWND* async_executor_handle);
int SetAsyncScriptDocument(HWND async_executor_handle);
int SetAsyncScriptElementArgument(HWND async_executor_handle,
const IECommandExecutor& command_executor,
const std::string& element_id);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
void Initialize(IHTMLDocument2* document,
const std::wstring& script_source,
const unsigned long argument_count);
Making JavaScript execution asynchronous for executeScript in IE Prior to this change, the execution of JavaScript via the executeScript method was synchronous. This would mean that if the script passed into the driver called the JavaScript `alert()`, `confirm()`, or `prompt()` functions, the WebDriver code would hang until the dialog was manually dismissed. Moving this to asynchronous execution allows the driver to be compliant with the W3C WebDriver Specification, that mandates that user prompts triggered by executeScript should be able to be handled by the WebDriver alert handling functions. However, this spec compliance comes at several costs. The first cost is complexity. The IE driver uses COM interfaces to communicate with Internet Explorer. COM is inherently single-threaded, and requires a fair amount of manipulation to allow accessing the objects on separate threads. This leads to requiring a fairly complex system of communication and synchronization between the threads to give the illusion of a synchronous script execution. The second cost is performance. Because of the need for synchronization, this change **may** introduce a performance hit in the IE driver. This is unfortunate, but unavoidable. The benefit of having user-initiated JavaScript not block and hang WebDriver code far outweighs whatever relatively small performance hit has been introduced.
2018-02-07 12:04:43 -08:00
int AddArgument(IElementManager* element_manager,
const Json::Value& arg);
int WalkArray(IElementManager* element_manager,
const Json::Value& array_value);
int WalkObject(IElementManager* element_manager,
const Json::Value& object_value);
Refactor IE user-initiated JavaScript execution to use JSON objects This IE driver refactor is internal, but should not change behavior of the driver. It is intended to let the driver's internal script executor use the direct internal JSON objects as arguments for script execution, deferring their conversion into variants until directly before execution.
2018-02-01 16:08:30 -08:00
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
CComPtr<IHTMLDocument2> script_engine_host_;
unsigned long argument_count_;
std::wstring source_code_;
long current_arg_index_;
Refactor IE user-initiated JavaScript execution to use JSON objects This IE driver refactor is internal, but should not change behavior of the driver. It is intended to let the driver's internal script executor use the direct internal JSON objects as arguments for script execution, deferring their conversion into variants until directly before execution.
2018-02-01 16:08:30 -08:00
Making JavaScript execution asynchronous for executeScript in IE Prior to this change, the execution of JavaScript via the executeScript method was synchronous. This would mean that if the script passed into the driver called the JavaScript `alert()`, `confirm()`, or `prompt()` functions, the WebDriver code would hang until the dialog was manually dismissed. Moving this to asynchronous execution allows the driver to be compliant with the W3C WebDriver Specification, that mandates that user prompts triggered by executeScript should be able to be handled by the WebDriver alert handling functions. However, this spec compliance comes at several costs. The first cost is complexity. The IE driver uses COM interfaces to communicate with Internet Explorer. COM is inherently single-threaded, and requires a fair amount of manipulation to allow accessing the objects on separate threads. This leads to requiring a fairly complex system of communication and synchronization between the threads to give the illusion of a synchronous script execution. The second cost is performance. Because of the need for synchronization, this change **may** introduce a performance hit in the IE driver. This is unfortunate, but unavoidable. The benefit of having user-initiated JavaScript not block and hang WebDriver code far outweighs whatever relatively small performance hit has been introduced.
2018-02-07 12:04:43 -08:00
std::wstring polling_source_code_;
Refactor IE user-initiated JavaScript execution to use JSON objects This IE driver refactor is internal, but should not change behavior of the driver. It is intended to let the driver's internal script executor use the direct internal JSON objects as arguments for script execution, deferring their conversion into variants until directly before execution.
2018-02-01 16:08:30 -08:00
HWND element_repository_handle_;
CPP linting. Removing global inclusion of std namespace.
2013-07-11 17:46:24 -04:00
std::vector<CComVariant> argument_array_;
Simplifying object handling code in IE driver. COM objects are now correctly referenced everywhere via smart pointers, and use of some aliased types is now replaced by the C++ primitives.
2013-03-25 13:34:23 -04:00
CComVariant result_;
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
};
} // namespace webdriver
#endif // WEBDRIVER_IE_SCRIPT_H_
Reference in New Issue Copy Permalink