Morph MORPH
SIGN IN SIGN UP
SeleniumHQ / selenium UNCLAIMED

A browser automation framework and ecosystem.

0 0 162 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");
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04: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.
Added ability to return text of JavaScript errors from IE Until this change, if the IE driver encountered an error in a user's JavaScript, there was no way to return the actual error text. This change fixes that. The text of the JavaScript error will be returned so it can be used as part of the exception thrown by the language bindings.
2018-10-01 10:10:49 -07:00
#ifndef WEBDRIVER_IE_ASYNCSCRIPTEXECUTOR_H_
#define WEBDRIVER_IE_ASYNCSCRIPTEXECUTOR_H_
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
#include <vector>
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
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
#include "IElementManager.h"
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
#include "messages.h"
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
#include "json.h"
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
namespace webdriver {
// Structure to be used for comunication between threads
struct AsyncScriptExecutorThreadContext {
HWND hwnd;
LPCTSTR script_source;
int script_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
HWND main_element_repository_handle;
LPCTSTR serialized_script_args;
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04: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
class ElementRepository;
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
// We use a CWindowImpl (creating a hidden window) here because we
// want to synchronize access to the command handler. For that we
// use SendMessage() most of the time, and SendMessage() requires
// a window 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
class AsyncScriptExecutor : public CWindowImpl<AsyncScriptExecutor>, public IElementManager {
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
public:
DECLARE_WND_CLASS(L"WebDriverAsyncAtomWndClass")
BEGIN_MSG_MAP(Session)
MESSAGE_HANDLER(WM_CREATE, OnCreate)
MESSAGE_HANDLER(WM_CLOSE, OnClose)
MESSAGE_HANDLER(WM_DESTROY, OnDestroy)
MESSAGE_HANDLER(WD_INIT, OnInit)
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_SET_DOCUMENT, OnSetDocument)
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
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_SET_ELEMENT_ARGUMENT, OnSetElementArgument)
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_IS_EXECUTION_READY, OnIsExecutionReady)
Refactored session shutdown code to properly wait for thread termination. Fixes issue #5543.
2013-05-23 16:52:54 -04:00
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_EXECUTE, OnExecuteScript)
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_IS_EXECUTION_COMPLETE, OnIsExecutionComplete)
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_DETACH_LISTENTER, OnDetachListener)
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_GET_RESULT, OnGetResult)
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
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_NOTIFY_ELEMENT_TRANSFERRED, OnNotifyElementTransferred)
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_SET_POLLING_SCRIPT, OnSetPollingScript)
MESSAGE_HANDLER(WD_ASYNC_SCRIPT_GET_REQUIRED_ELEMENT_LIST, OnGetRequiredElementList)
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
END_MSG_MAP()
LRESULT OnCreate(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnClose(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnDestroy(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnInit(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnSetDocument(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
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
LRESULT OnSetElementArgument(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnIsExecutionReady(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
LRESULT OnExecuteScript(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnIsExecutionComplete(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnDetachListener(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnGetResult(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
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
LRESULT OnNotifyElementTransferred(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnSetPollingScript(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
LRESULT OnGetRequiredElementList(UINT uMsg, WPARAM wParam, LPARAM lParam, BOOL& bHandled);
int GetManagedElement(const std::string& element_id,
ElementHandle* element_wrapper) const;
bool AddManagedElement(IHTMLElement* element,
ElementHandle* element_wrapper);
void RemoveManagedElement(const std::string& element_id);
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
static unsigned int WINAPI ThreadProc(LPVOID lpParameter);
private:
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
void GetElementIdList(const Json::Value& json_object);
bool WaitForPollingScript(void);
void TransferReturnedElements(void);
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
void ReplaceTransferredElementResult(std::string original_element_id,
std::string element_id,
Json::Value* 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
ElementRepository* element_repository_;
HWND main_element_repository_handle_;
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
CComPtr<IHTMLDocument2> script_host_;
std::vector<CComVariant> script_arguments_;
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::vector<std::string> element_id_list_;
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
std::wstring script_source_code_;
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_script_source_code_;
Json::Value script_args_;
Json::Value script_result_;
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
int script_argument_count_;
int script_argument_index_;
int status_code_;
bool is_execution_completed_;
bool is_listener_attached_;
};
} // namespace webdriver
Added ability to return text of JavaScript errors from IE Until this change, if the IE driver encountered an error in a user's JavaScript, there was no way to return the actual error text. This change fixes that. The text of the JavaScript error will be returned so it can be used as part of the exception thrown by the language bindings.
2018-10-01 10:10:49 -07:00
#endif // WEBDRIVER_IE_ASYNCSCRIPTEXECUTOR_H_
Refactoring asynchronous execution of JavaScript in IE driver This introduces a new method for executing JavaScript functions asynchronously via a new thread. This centralizes the code used to execute automation atoms that may cause an alert to display (like click or submit).
2013-05-01 13:12:27 -04:00
Reference in New Issue Copy Permalink