Morph MORPH
SIGN IN SIGN UP
SeleniumHQ / selenium UNCLAIMED

A browser automation framework and ecosystem.

34170 0 120 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.
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 "ElementFinder.h"
#include "errorcodes.h"
#include "logging.h"
#include "json.h"
#include "DocumentHost.h"
#include "Element.h"
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
#include "Generated/atoms.h"
#include "Generated/sizzle.h"
#include "IECommandExecutor.h"
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
#include "Script.h"
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
namespace webdriver {
ElementFinder::ElementFinder() {
}
ElementFinder::~ElementFinder() {
}
int ElementFinder::FindElement(const IECommandExecutor& executor,
const ElementHandle parent_wrapper,
const std::wstring& mechanism,
const std::wstring& criteria,
Json::Value* found_element) {
LOG(TRACE) << "Entering ElementFinder::FindElement";
BrowserHandle browser;
int status_code = executor.GetCurrentBrowser(&browser);
Updating IEDriver native code to use the new WD_SUCCESS #define instead of just SUCCESS
2013-01-16 14:37:30 -05:00
if (status_code == WD_SUCCESS) {
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
if (mechanism == L"css") {
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
if (!this->HasNativeCssSelectorEngine(executor)) {
LOG(DEBUG) << "Element location strategy is CSS selectors, but "
<< "document does not support CSS selectors. Falling back "
<< "to using the Sizzle JavaScript CSS selector engine.";
Reducing JavaScript errors during findElement(s) for IE In most cases, executing JavaScript is an atomic action for the IE driver. However, in the off chance that there is a page refresh during the execution of JavaScript, converting the result of the script to a JSON object for serialization might cause an error, in which case we should return the appropriate error to the caller. One place, however, where this might be common is executing findElement(s) across a page navigation. This change makes the driver return the proper error in the post-processing of a script execution. It also recognizes the findElement(s) case, ignoring JavaScript errors in finding elements, and returning the proper structure (an empty list or a "no such element" error) in its place. This lets things like explicit waits retry the find, which may succeed once the page navigation has completed and the DOM available for querying again.
2018-12-20 08:46:35 -08:00
status_code = this->FindElementUsingSizzle(executor,
parent_wrapper,
criteria,
found_element);
if (status_code != WD_SUCCESS) {
LOG(WARN) << "A JavaScript error was encountered finding elements using Sizzle.";
status_code = ENOSUCHELEMENT;
}
return status_code;
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
}
}
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
Remove wstring address usages in log messages. It fixes messages in log like: ... ElementFinder.cpp(49) 55097F38xpath = //*[@id='aaa']
2013-04-29 23:03:15 +04:00
LOG(DEBUG) << "Using FindElement atom to locate element having "
Implement ability to specify IE launch API and IE CLI switches For some cases, it may be necessary to launch IE in Private mode for testing in parallel on a single node. To support this, there must be a way to force the IE driver to use the Windows CreateProcess() API to launch IE so that the user can specify command-line switches. To preserve the ability to locate the correct process for IE versions 8 and higher, a registry value must be set, and the IE driver checks for the registry value before launching IE. Signed-off-by: Jim Evans <james.h.evans.jr@gmail.com>
2013-04-10 00:02:15 +04:00
<< LOGWSTRING(mechanism) << " = "
<< LOGWSTRING(criteria);
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
CComPtr<IHTMLDocument2> doc;
browser->GetDocument(&doc);
Adding IE-specific atoms to eliminate round-trips through IE's JS engine The findElement and findElements atoms take a JavaScript object as their first parameter. Until now, that facilitated a round-trip through the IE JavaScript engine to be able to create the JavaScript object to pass into the atom function. We are now creating IE-specific JavaScript functions that wrap those two atoms, and take simple strings as arguments, which lets the IE driver call the atom directly without having to call a separate script that simply creates the JavaScript criteria object.
2013-07-05 14:36:04 -04:00
std::wstring script_source(L"(function() { return (");
script_source += atoms::asString(atoms::FIND_ELEMENT);
script_source += L")})();";
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
Adding IE-specific atoms to eliminate round-trips through IE's JS engine The findElement and findElements atoms take a JavaScript object as their first parameter. Until now, that facilitated a round-trip through the IE JavaScript engine to be able to create the JavaScript object to pass into the atom function. We are now creating IE-specific JavaScript functions that wrap those two atoms, and take simple strings as arguments, which lets the IE driver call the atom directly without having to call a separate script that simply creates the JavaScript criteria object.
2013-07-05 14:36:04 -04:00
Script script_wrapper(doc, script_source, 3);
script_wrapper.AddArgument(mechanism);
script_wrapper.AddArgument(criteria);
if (parent_wrapper) {
script_wrapper.AddArgument(parent_wrapper->element());
}
status_code = script_wrapper.Execute();
if (status_code == WD_SUCCESS) {
Changes to simplify the execution of finding elements. The driver now delegates more of the error handling of finding elements to the JavaScript automation atoms. This has the effect of simplifying the code within the driver, and synchronizes the error-case behavior with other implementations.
2016-01-22 09:51:38 -08:00
Json::Value atom_result;
Reducing JavaScript errors during findElement(s) for IE In most cases, executing JavaScript is an atomic action for the IE driver. However, in the off chance that there is a page refresh during the execution of JavaScript, converting the result of the script to a JSON object for serialization might cause an error, in which case we should return the appropriate error to the caller. One place, however, where this might be common is executing findElement(s) across a page navigation. This change makes the driver return the proper error in the post-processing of a script execution. It also recognizes the findElement(s) case, ignoring JavaScript errors in finding elements, and returning the proper structure (an empty list or a "no such element" error) in its place. This lets things like explicit waits retry the find, which may succeed once the page navigation has completed and the DOM available for querying again.
2018-12-20 08:46:35 -08:00
int converted_status_code = script_wrapper.ConvertResultToJsonValue(executor, &atom_result);
if (converted_status_code != WD_SUCCESS) {
LOG(WARN) << "Could not convert return from findElements atom to JSON value";
status_code = ENOSUCHELEMENT;
} else {
int atom_status_code = atom_result["status"].asInt();
Json::Value atom_value = atom_result["value"];
status_code = atom_status_code;
*found_element = atom_result["value"];
}
} else {
Update IE driver to return NoSuchElement on JavaScript atom errors Hitting a JavaScript error with the atom is an unrecoverable error. The most common case of this for IE is when there is a page refresh, navigation, or similar, and the driver is polling for element presence. The calling code can't do anything about it, so we might as well just log and return "no such element" error code. In the common case, this means that the error will be transitory, and will sort itself out once the DOM returns to normal after the page transition is completed. Note carefully that this is an extreme hack, and has the potential to be masking a very serious problem in the driver.
2016-02-23 11:13:24 -08:00
// Hitting a JavaScript error with the atom is an unrecoverable
// error. The most common case of this for IE is when there is a
// page refresh, navigation, or similar, and the driver is polling
// for element presence. The calling code can't do anything about
// it, so we might as well just log and return the "no such element"
// error code. In the common case, this means that the error will be
// transitory, and will sort itself out once the DOM returns to normal
// after the page transition is completed. Note carefully that this
// is an extreme hack, and has the potential to be papering over a
// very serious problem in the driver.
LOG(WARN) << "A JavaScript error was encountered executing the findElement atom.";
Reducing JavaScript errors during findElement(s) for IE In most cases, executing JavaScript is an atomic action for the IE driver. However, in the off chance that there is a page refresh during the execution of JavaScript, converting the result of the script to a JSON object for serialization might cause an error, in which case we should return the appropriate error to the caller. One place, however, where this might be common is executing findElement(s) across a page navigation. This change makes the driver return the proper error in the post-processing of a script execution. It also recognizes the findElement(s) case, ignoring JavaScript errors in finding elements, and returning the proper structure (an empty list or a "no such element" error) in its place. This lets things like explicit waits retry the find, which may succeed once the page navigation has completed and the DOM available for querying again.
2018-12-20 08:46:35 -08:00
status_code = ENOSUCHELEMENT;
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
}
} else {
LOG(WARN) << "Unable to get browser";
}
return status_code;
}
int ElementFinder::FindElements(const IECommandExecutor& executor,
const ElementHandle parent_wrapper,
const std::wstring& mechanism,
const std::wstring& criteria,
Json::Value* found_elements) {
LOG(TRACE) << "Entering ElementFinder::FindElements";
BrowserHandle browser;
int status_code = executor.GetCurrentBrowser(&browser);
Updating IEDriver native code to use the new WD_SUCCESS #define instead of just SUCCESS
2013-01-16 14:37:30 -05:00
if (status_code == WD_SUCCESS) {
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
if (mechanism == L"css") {
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
if (!this->HasNativeCssSelectorEngine(executor)) {
LOG(DEBUG) << "Element location strategy is CSS selectors, but "
<< "document does not support CSS selectors. Falling back "
<< "to using the Sizzle JavaScript CSS selector engine.";
Reducing JavaScript errors during findElement(s) for IE In most cases, executing JavaScript is an atomic action for the IE driver. However, in the off chance that there is a page refresh during the execution of JavaScript, converting the result of the script to a JSON object for serialization might cause an error, in which case we should return the appropriate error to the caller. One place, however, where this might be common is executing findElement(s) across a page navigation. This change makes the driver return the proper error in the post-processing of a script execution. It also recognizes the findElement(s) case, ignoring JavaScript errors in finding elements, and returning the proper structure (an empty list or a "no such element" error) in its place. This lets things like explicit waits retry the find, which may succeed once the page navigation has completed and the DOM available for querying again.
2018-12-20 08:46:35 -08:00
status_code = this->FindElementsUsingSizzle(executor,
parent_wrapper,
criteria,
found_elements);
if (status_code != WD_SUCCESS) {
LOG(WARN) << "A JavaScript error was encountered finding elements using Sizzle.";
status_code = WD_SUCCESS;
*found_elements = Json::Value(Json::arrayValue);
}
return status_code;
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
}
}
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
Remove wstring address usages in log messages. It fixes messages in log like: ... ElementFinder.cpp(49) 55097F38xpath = //*[@id='aaa']
2013-04-29 23:03:15 +04:00
LOG(DEBUG) << "Using FindElements atom to locate element having "
Implement ability to specify IE launch API and IE CLI switches For some cases, it may be necessary to launch IE in Private mode for testing in parallel on a single node. To support this, there must be a way to force the IE driver to use the Windows CreateProcess() API to launch IE so that the user can specify command-line switches. To preserve the ability to locate the correct process for IE versions 8 and higher, a registry value must be set, and the IE driver checks for the registry value before launching IE. Signed-off-by: Jim Evans <james.h.evans.jr@gmail.com>
2013-04-10 00:02:15 +04:00
<< LOGWSTRING(mechanism) << " = "
<< LOGWSTRING(criteria);
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
CComPtr<IHTMLDocument2> doc;
browser->GetDocument(&doc);
Adding IE-specific atoms to eliminate round-trips through IE's JS engine The findElement and findElements atoms take a JavaScript object as their first parameter. Until now, that facilitated a round-trip through the IE JavaScript engine to be able to create the JavaScript object to pass into the atom function. We are now creating IE-specific JavaScript functions that wrap those two atoms, and take simple strings as arguments, which lets the IE driver call the atom directly without having to call a separate script that simply creates the JavaScript criteria object.
2013-07-05 14:36:04 -04:00
std::wstring script_source(L"(function() { return (");
script_source += atoms::asString(atoms::FIND_ELEMENTS);
script_source += L")})();";
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
Adding IE-specific atoms to eliminate round-trips through IE's JS engine The findElement and findElements atoms take a JavaScript object as their first parameter. Until now, that facilitated a round-trip through the IE JavaScript engine to be able to create the JavaScript object to pass into the atom function. We are now creating IE-specific JavaScript functions that wrap those two atoms, and take simple strings as arguments, which lets the IE driver call the atom directly without having to call a separate script that simply creates the JavaScript criteria object.
2013-07-05 14:36:04 -04:00
Script script_wrapper(doc, script_source, 3);
script_wrapper.AddArgument(mechanism);
script_wrapper.AddArgument(criteria);
if (parent_wrapper) {
script_wrapper.AddArgument(parent_wrapper->element());
}
status_code = script_wrapper.Execute();
if (status_code == WD_SUCCESS) {
Changes to simplify the execution of finding elements. The driver now delegates more of the error handling of finding elements to the JavaScript automation atoms. This has the effect of simplifying the code within the driver, and synchronizes the error-case behavior with other implementations.
2016-01-22 09:51:38 -08:00
Json::Value atom_result;
Reducing JavaScript errors during findElement(s) for IE In most cases, executing JavaScript is an atomic action for the IE driver. However, in the off chance that there is a page refresh during the execution of JavaScript, converting the result of the script to a JSON object for serialization might cause an error, in which case we should return the appropriate error to the caller. One place, however, where this might be common is executing findElement(s) across a page navigation. This change makes the driver return the proper error in the post-processing of a script execution. It also recognizes the findElement(s) case, ignoring JavaScript errors in finding elements, and returning the proper structure (an empty list or a "no such element" error) in its place. This lets things like explicit waits retry the find, which may succeed once the page navigation has completed and the DOM available for querying again.
2018-12-20 08:46:35 -08:00
int converted_status_code = script_wrapper.ConvertResultToJsonValue(executor, &atom_result);
if (converted_status_code != WD_SUCCESS) {
LOG(WARN) << "Could not convert return from findElements atom to JSON value";
status_code = WD_SUCCESS;
*found_elements = Json::Value(Json::arrayValue);
} else {
int atom_status_code = atom_result["status"].asInt();
Json::Value atom_value = atom_result["value"];
status_code = atom_status_code;
*found_elements = atom_result["value"];
}
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
} else {
Update IE driver to return NoSuchElement on JavaScript atom errors Hitting a JavaScript error with the atom is an unrecoverable error. The most common case of this for IE is when there is a page refresh, navigation, or similar, and the driver is polling for element presence. The calling code can't do anything about it, so we might as well just log and return "no such element" error code. In the common case, this means that the error will be transitory, and will sort itself out once the DOM returns to normal after the page transition is completed. Note carefully that this is an extreme hack, and has the potential to be masking a very serious problem in the driver.
2016-02-23 11:13:24 -08:00
// Hitting a JavaScript error with the atom is an unrecoverable
// error. The most common case of this for IE is when there is a
// page refresh, navigation, or similar, and the driver is polling
// for element presence. The calling code can't do anything about
Updated IE driver to not error on findElements JavaScript atom errors. Hitting a JavaScript error with the atom is an unrecoverable error. The most common case of this for IE is when there is a page refresh, navigation, or similar, and the driver is polling for element presence. The calling code can't do anything about it, so we might as well just log and return success with an empty list. This was fixed in 2.52.1 for the "find single element" case, but was not completely fixed for the "find multiple elements" case. As before, this is an extreme hack, and has the potential to be masking a very serious problem in the driver.
2016-03-07 09:05:19 -08:00
// it, so we might as well just log and return. In the common case,
Update IE driver to return NoSuchElement on JavaScript atom errors Hitting a JavaScript error with the atom is an unrecoverable error. The most common case of this for IE is when there is a page refresh, navigation, or similar, and the driver is polling for element presence. The calling code can't do anything about it, so we might as well just log and return "no such element" error code. In the common case, this means that the error will be transitory, and will sort itself out once the DOM returns to normal after the page transition is completed. Note carefully that this is an extreme hack, and has the potential to be masking a very serious problem in the driver.
2016-02-23 11:13:24 -08:00
// this means that the error will be transitory, and will sort
// itself out once the DOM returns to normal after the page transition
Updated IE driver to not error on findElements JavaScript atom errors. Hitting a JavaScript error with the atom is an unrecoverable error. The most common case of this for IE is when there is a page refresh, navigation, or similar, and the driver is polling for element presence. The calling code can't do anything about it, so we might as well just log and return success with an empty list. This was fixed in 2.52.1 for the "find single element" case, but was not completely fixed for the "find multiple elements" case. As before, this is an extreme hack, and has the potential to be masking a very serious problem in the driver.
2016-03-07 09:05:19 -08:00
// is completed. Return an empty array, and a success error code.
Reducing JavaScript errors during findElement(s) for IE In most cases, executing JavaScript is an atomic action for the IE driver. However, in the off chance that there is a page refresh during the execution of JavaScript, converting the result of the script to a JSON object for serialization might cause an error, in which case we should return the appropriate error to the caller. One place, however, where this might be common is executing findElement(s) across a page navigation. This change makes the driver return the proper error in the post-processing of a script execution. It also recognizes the findElement(s) case, ignoring JavaScript errors in finding elements, and returning the proper structure (an empty list or a "no such element" error) in its place. This lets things like explicit waits retry the find, which may succeed once the page navigation has completed and the DOM available for querying again.
2018-12-20 08:46:35 -08:00
LOG(WARN) << "A JavaScript error was encountered executing the findElements atom.";
Updated IE driver to not error on findElements JavaScript atom errors. Hitting a JavaScript error with the atom is an unrecoverable error. The most common case of this for IE is when there is a page refresh, navigation, or similar, and the driver is polling for element presence. The calling code can't do anything about it, so we might as well just log and return success with an empty list. This was fixed in 2.52.1 for the "find single element" case, but was not completely fixed for the "find multiple elements" case. As before, this is an extreme hack, and has the potential to be masking a very serious problem in the driver.
2016-03-07 09:05:19 -08:00
status_code = WD_SUCCESS;
*found_elements = Json::Value(Json::arrayValue);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
}
} else {
LOG(WARN) << "Unable to get browser";
}
return status_code;
}
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
int ElementFinder::FindElementUsingSizzle(const IECommandExecutor& executor,
const ElementHandle parent_wrapper,
const std::wstring& criteria,
Json::Value* found_element) {
LOG(TRACE) << "Entering ElementFinder::FindElementUsingSizzle";
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
int result;
BrowserHandle browser;
result = executor.GetCurrentBrowser(&browser);
Updating IEDriver native code to use the new WD_SUCCESS #define instead of just SUCCESS
2013-01-16 14:37:30 -05:00
if (result != WD_SUCCESS) {
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
LOG(WARN) << "Unable to get browser";
return result;
}
std::wstring script_source(L"(function() { return function(){ if (!window.Sizzle) {");
script_source += atoms::asString(atoms::SIZZLE);
script_source += L"}\n";
script_source += L"var root = arguments[1] ? arguments[1] : document.documentElement;";
script_source += L"if (root['querySelector']) { return root.querySelector(arguments[0]); } ";
script_source += L"var results = []; Sizzle(arguments[0], root, results);";
script_source += L"return results.length > 0 ? results[0] : null;";
script_source += L"};})();";
CComPtr<IHTMLDocument2> doc;
browser->GetDocument(&doc);
Script script_wrapper(doc, script_source, 2);
script_wrapper.AddArgument(criteria);
if (parent_wrapper) {
CComPtr<IHTMLElement> parent(parent_wrapper->element());
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
script_wrapper.AddArgument(parent);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
}
result = script_wrapper.Execute();
Updating IEDriver native code to use the new WD_SUCCESS #define instead of just SUCCESS
2013-01-16 14:37:30 -05:00
if (result == WD_SUCCESS) {
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
if (!script_wrapper.ResultIsElement()) {
LOG(WARN) << "Found result is not element";
result = ENOSUCHELEMENT;
} else {
result = script_wrapper.ConvertResultToJsonValue(executor,
found_element);
}
} else {
LOG(WARN) << "Unable to find elements";
result = ENOSUCHELEMENT;
}
return result;
}
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
int ElementFinder::FindElementsUsingSizzle(const IECommandExecutor& executor,
const ElementHandle parent_wrapper,
const std::wstring& criteria,
Json::Value* found_elements) {
LOG(TRACE) << "Entering ElementFinder::FindElementsUsingSizzle";
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
int result;
Attempting fix for finding multiple elements with invalid CSS selectors.
2014-01-10 12:04:47 -05:00
if (criteria == L"") {
// Apparently, Sizzle will happily return an empty array for an empty
// string as the selector. We do not want this.
return ENOSUCHELEMENT;
}
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
BrowserHandle browser;
result = executor.GetCurrentBrowser(&browser);
Updating IEDriver native code to use the new WD_SUCCESS #define instead of just SUCCESS
2013-01-16 14:37:30 -05:00
if (result != WD_SUCCESS) {
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
LOG(WARN) << "Unable to get browser";
return result;
}
std::wstring script_source(L"(function() { return function(){ if (!window.Sizzle) {");
script_source += atoms::asString(atoms::SIZZLE);
script_source += L"}\n";
script_source += L"var root = arguments[1] ? arguments[1] : document.documentElement;";
script_source += L"if (root['querySelectorAll']) { return root.querySelectorAll(arguments[0]); } ";
Attempting fix for finding multiple elements with invalid CSS selectors.
2014-01-10 12:04:47 -05:00
script_source += L"var results = []; try { Sizzle(arguments[0], root, results); } catch(ex) { results = null; }";
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
script_source += L"return results;";
script_source += L"};})();";
CComPtr<IHTMLDocument2> doc;
browser->GetDocument(&doc);
Script script_wrapper(doc, script_source, 2);
script_wrapper.AddArgument(criteria);
if (parent_wrapper) {
// Use a copy for the parent element?
CComPtr<IHTMLElement> parent(parent_wrapper->element());
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
script_wrapper.AddArgument(parent);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
}
result = script_wrapper.Execute();
Updating IEDriver native code to use the new WD_SUCCESS #define instead of just SUCCESS
2013-01-16 14:37:30 -05:00
if (result == WD_SUCCESS) {
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
CComVariant snapshot = script_wrapper.result();
Attempting fix for finding multiple elements with invalid CSS selectors.
2014-01-10 12:04:47 -05:00
if (snapshot.vt == VT_NULL || snapshot.vt == VT_EMPTY) {
// We explicitly caught an error from Sizzle. Return ENOSUCHELEMENT.
return ENOSUCHELEMENT;
}
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
std::wstring get_element_count_script = L"(function(){return function() {return arguments[0].length;}})();";
Script get_element_count_script_wrapper(doc, get_element_count_script, 1);
get_element_count_script_wrapper.AddArgument(snapshot);
result = get_element_count_script_wrapper.Execute();
Updating IEDriver native code to use the new WD_SUCCESS #define instead of just SUCCESS
2013-01-16 14:37:30 -05:00
if (result == WD_SUCCESS) {
Fixed finding elements where native CSS selector engine cannot be found
2016-01-22 14:13:33 -08:00
*found_elements = Json::Value(Json::arrayValue);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
if (!get_element_count_script_wrapper.ResultIsInteger()) {
LOG(WARN) << "Found elements count is not integer";
result = EUNEXPECTEDJSERROR;
} else {
long length = get_element_count_script_wrapper.result().lVal;
std::wstring get_next_element_script = L"(function(){return function() {return arguments[0][arguments[1]];}})();";
for (long i = 0; i < length; ++i) {
Script get_element_script_wrapper(doc, get_next_element_script, 2);
get_element_script_wrapper.AddArgument(snapshot);
get_element_script_wrapper.AddArgument(i);
result = get_element_script_wrapper.Execute();
Updating IEDriver native code to use the new WD_SUCCESS #define instead of just SUCCESS
2013-01-16 14:37:30 -05:00
if (result == WD_SUCCESS) {
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
Json::Value json_element;
get_element_script_wrapper.ConvertResultToJsonValue(executor,
&json_element);
found_elements->append(json_element);
} else {
LOG(WARN) << "Unable to get " << i << " found element";
}
}
}
} else {
LOG(WARN) << "Unable to get count of found elements";
result = EUNEXPECTEDJSERROR;
}
} else {
LOG(WARN) << "Execution returned error";
}
return result;
}
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
bool ElementFinder::HasNativeCssSelectorEngine(const IECommandExecutor& executor) {
LOG(TRACE) << "Entering ElementFinder::HasNativeCssSelectorEngine";
BrowserHandle browser;
executor.GetCurrentBrowser(&browser);
std::wstring script_source(L"(function() { return function(){");
script_source += L"var root = document.documentElement;";
script_source += L"if (root['querySelectorAll']) { return true; } ";
script_source += L"return false;";
script_source += L"};})();";
CComPtr<IHTMLDocument2> doc;
browser->GetDocument(&doc);
Script script_wrapper(doc, script_source, 0);
Reducing JavaScript errors during findElement(s) for IE In most cases, executing JavaScript is an atomic action for the IE driver. However, in the off chance that there is a page refresh during the execution of JavaScript, converting the result of the script to a JSON object for serialization might cause an error, in which case we should return the appropriate error to the caller. One place, however, where this might be common is executing findElement(s) across a page navigation. This change makes the driver return the proper error in the post-processing of a script execution. It also recognizes the findElement(s) case, ignoring JavaScript errors in finding elements, and returning the proper structure (an empty list or a "no such element" error) in its place. This lets things like explicit waits retry the find, which may succeed once the page navigation has completed and the DOM available for querying again.
2018-12-20 08:46:35 -08:00
int status_code = script_wrapper.Execute();
if (status_code != WD_SUCCESS) {
// If executing the script yields an error, then falling back to
// Sizzle will never work, so assume there is a native CSS selector
// engine.
return true;
}
Refactoring IE element finder to make clearer when Sizzle is used. Previously, it was not as easy to determine from IEDriverServer.exe logs when Sizzle was being used for finding elements by CSS selector. It is now explicitly called out and logged. Also, it now insures that the automation atoms are being used when Sizzle is not necessary.
2013-03-26 09:14:38 -04:00
return script_wrapper.result().boolVal == VARIANT_TRUE;
}
Reducing JavaScript errors during findElement(s) for IE In most cases, executing JavaScript is an atomic action for the IE driver. However, in the off chance that there is a page refresh during the execution of JavaScript, converting the result of the script to a JSON object for serialization might cause an error, in which case we should return the appropriate error to the caller. One place, however, where this might be common is executing findElement(s) across a page navigation. This change makes the driver return the proper error in the post-processing of a script execution. It also recognizes the findElement(s) case, ignoring JavaScript errors in finding elements, and returning the proper structure (an empty list or a "no such element" error) in its place. This lets things like explicit waits retry the find, which may succeed once the page navigation has completed and the DOM available for querying again.
2018-12-20 08:46:35 -08:00
} // namespace webdriver
Reference in New Issue Copy Permalink