Morph MORPH
SIGN IN SIGN UP
SeleniumHQ / selenium UNCLAIMED

A browser automation framework and ecosystem.

0 0 244 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_ELEMENT_H_
#define WEBDRIVER_IE_ELEMENT_H_
Fixing issues found via static code analysis for IE driver. No functional changes
2013-02-25 11:32:30 -05:00
#include <memory>
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
#include <string>
#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
#include "ElementScrollBehavior.h"
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
#include "LocationInfo.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
#define JSON_ELEMENT_PROPERTY_NAME "element-6066-11e4-a52e-4f735466cecf"
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 {
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 Browser;
class Element {
public:
Element(IHTMLElement* element, HWND containing_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
Element(IHTMLElement* element,
HWND containing_window_handle,
const std::string& element_id);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
virtual ~Element(void);
Json::Value ConvertToJson(void);
std::string GetTagName(void);
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
int GetLocationOnceScrolledIntoView(const ElementScrollBehavior scroll,
Allow click on visible part of element if center can't be scrolled into view This fixes issue #4390 for IE, but there are other fixes required for Firefox before the issue can be truly closed. Signed-off-by: Jim Evans <james.h.evans.jr@gmail.com>
2013-04-10 03:55:39 +04:00
LocationInfo* location,
std::vector<LocationInfo>* frame_locations);
Modifying mouse event handling to match W3C Specification THIS IS A POTENTIAL BREAKING CHANGE. The simulation of mouse movement for the actions command now conforms to the W3C WebDriver Specification for mouse movement. This means that offsets in elements are now measured from the center of the element instead of the top-left, which was the previous behavior. Additionally, attempting to move the mouse pointer outside the browser view port will result in a "mouse movement out of bounds" error. While users should be aware that this might cause code using user interactions to fail, not that the behavior is now consistent with the behavior outlined in the specification, and the behavior of geckodriver in particular.
2018-02-23 13:55:26 -08:00
int GetStaticClickLocation(LocationInfo* click_location);
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
int GetClickLocation(const ElementScrollBehavior scroll_behavior,
Refactored IE driver element click code to all use InputManager class. Previously, WebElement.click() used a different code path than the Advanced User Interactions API. These code paths are now unified for the native events case.
2013-05-09 16:20:57 -04:00
LocationInfo* element_location,
LocationInfo* click_location);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
int GetAttributeValue(const std::string& attribute_name,
Fixing getElementProperty to return proper data type. Previously, the getElementProperty command would coerce the property value to a string. This is not correct behavior as specified in the W3C spec.
2018-02-22 07:07:33 -08:00
VARIANT* attribute_value);
Updated IE driver to better support W3C WebDriver Specification This is a large update that includes implementation of the following things that are part of the WebDriver spec: * Implement the "get element property" command * Implement the "get named cookie" command * Implement the "minimize window" command * Implement the "fullscreen window" command * Update "set window rect" command to correctly recognize and restore from minimized or full screen state * Fix the "release actions" command to properly roll back all pending actions * Update the "perform actions" command to be more robust for pointer actions * Fix alert handling to handle dialogs with the "Do not show any more dialogs" check box * Added handling for the "dismiss and notify" and "accept and notify" user prompt handler states
2017-08-31 09:41:44 -07:00
int GetPropertyValue(const std::string& property_name,
Fixing getElementProperty to return proper data type. Previously, the getElementProperty command would coerce the property value to a string. This is not correct behavior as specified in the W3C spec.
2018-02-22 07:07:33 -08:00
VARIANT* property_value);
Correcting logic for invisible element coordinate calculation on IE6 and 7.
2013-07-08 13:43:53 -04:00
int GetCssPropertyValue(const std::string& property_name,
std::string* property_value);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
Changing IE driver to allow interaction with elements where opacity = 0 The isDisplayed will still return false for those elements, as is consistent with drivers for Firefox and Chrome. Fixes issue #503.
2015-04-29 11:09:13 -04:00
int IsDisplayed(bool ignore_opacity, bool* result);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
bool IsEnabled(void);
Updating IE to properly find XML documents for element enabled and CSS values
2018-08-31 07:32:49 -07:00
bool IsXmlDocument(IHTMLDocument2* doc);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
bool IsSelected(void);
Modified to check the interactable state of an element before clicking. The clear Automation Atom normally checks that an element is interactable before attempting to clear it. Unfortunately, when the atom is run on a separate thread in legacy IE, the error states do not get propagated back to the calling thread properly. To avoid this problem, the driver will check the interactable state before calling the clear atom. To facilitate this, a new atom has been exposed for checking the interactable state.
2013-05-02 09:17:28 -04:00
bool IsInteractable(void);
Modified to check the editable state of an element before clearing. The clear Automation Atom normally checks that an element is interactable and editable before attempting to clear it. A previous change fixed the case for checking the interactable state, but not the editable state. The driver will now check the editable state as well. To facilitate this, a new atom has been exposed for checking the editable state.
2013-05-02 11:08:07 -04:00
bool IsEditable(void);
Adding IsFocusable method to IE driver Element class
2018-03-17 12:21:27 -07:00
bool IsFocusable(void);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
bool IsAttachedToDom(void);
Refactoring IE element's parent document detection to be the focused doc
2018-02-05 12:52:43 -08:00
bool IsDocumentFocused(IHTMLDocument2* focused_doc);
Adding detection of intercepted element clicks to IE This brings the IE driver into alignment with the Chrome and Firefox (geckodriver) drivers, in that it detects when an element attempting to be clicked on is covered in the z-order by another element. Do note that this may cause different behavior from previous versions of the IE driver for WebDriver code that runs only on IE. For code that runs cross-browser, this should now yield the same behavior across platforms.
2018-03-10 13:10:55 -08:00
bool IsObscured(LocationInfo* click_location,
Adding hack to obscured element check for label elements in IE As per the W3C WebDriver Specification, the IE driver uses elementsFromPoint to determine whether an element being clicked on is obscured. However, there is a bug in the IE implementation of elementsFromPoint that if the element parent tree contains a <label> element, that element is omitted from the list of elements returned by elementsFromPoint. This change is to work around that bug. The solution implemented here is to check if the top-most element as returned by elementFromPoint is a direct descendent of the element we want to click on, and the element we want to click on is a <label>, we assume the element is not obscured. Note carefully that this is a hack of the highest order, and there's every likelihood that some page, somewhere will fail this check. Upon receiving an issue report with a complete reproduction case that includes a page clearly demonstrating the issue, we will then revisit this algorithm.
2018-10-08 16:00:35 -07:00
long* obscuring_element_index,
Adding detection of intercepted element clicks to IE This brings the IE driver into alignment with the Chrome and Firefox (geckodriver) drivers, in that it detects when an element attempting to be clicked on is covered in the z-order by another element. Do note that this may cause different behavior from previous versions of the IE driver for WebDriver code that runs only on IE. For code that runs cross-browser, this should now yield the same behavior across platforms.
2018-03-10 13:10:55 -08:00
std::string* obscuring_element_description);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
Updating IE element obscured algorithm to handle shadow DOM polyfills Shadow DOM for IE is problematic. Shadow DOM is only available in IE as a polyfill. If an element is part of a Shadow DOM (using a polyfill), IE's elementsFromPoint implementation will show the component elements, not necessarily the Web Component root element itself. If the direct parent of the Web Component host element is in this list, then it counts as a direct descendent, and won't be obscured. Note that a potential enhancement to this change is to walk the DOM tree up until an ancestor is found that does not have a shadow root, but that enhancement is not implemented at present.
2019-01-02 09:35:38 -08:00
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
std::string element_id(void) const { return this->element_id_; }
IHTMLElement* element(void) { return this->element_; }
private:
Refactored calculations to the size of the visible view port. There are circumstances where IE can have no vertical scroll bar. In these cases, the IE driver would assume there was a vertical scroll bar, which would make the actual width of the document larger than the computed width of the window. This, in turn, would make the driver assume there was a horizontal scroll bar, which would imply that absolutely-positioned elements at the bottom of the page would not be seen as clickable.
2013-08-20 16:58:46 -04:00
int GetLocation(LocationInfo* location,
std::vector<LocationInfo>* frame_locations);
LocationInfo CalculateClickPoint(const LocationInfo location,
const bool document_contains_frames);
bool GetClickableViewPortLocation(const bool document_contains_frames,
LocationInfo* location);
bool IsLocationInViewPort(const LocationInfo location,
const bool document_contains_frames);
bool IsLocationVisibleInFrames(const LocationInfo location,
const std::vector<LocationInfo> frame_locations);
Updating IE scroll-into-view algorithm for element click This update makes the scroll-into-view algorithm for element click to be compliant with the W3C WebDriver Specification.
2018-11-19 10:08:24 -08:00
bool IsHiddenByOverflow(const LocationInfo element_location,
const LocationInfo click_location);
Updating IE to prep for refactor of element click point calculation
2019-07-22 14:10:08 -07:00
bool IsEntirelyHiddenByOverflow(void);
bool ScrollWithinOverflow(const LocationInfo element_location);
Refactored calculations to the size of the visible view port. There are circumstances where IE can have no vertical scroll bar. In these cases, the IE driver would assume there was a vertical scroll bar, which would make the actual width of the document larger than the computed width of the window. This, in turn, would make the driver assume there was a horizontal scroll bar, which would imply that absolutely-positioned elements at the bottom of the page would not be seen as clickable.
2013-08-20 16:58:46 -04:00
bool AppendFrameDetails(std::vector<LocationInfo>* frame_locations);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
int GetContainingDocument(const bool use_dom_node, IHTMLDocument2** doc);
int GetDocumentFromWindow(IHTMLWindow2* parent_window,
IHTMLDocument2** parent_doc);
Updating IE element obscured algorithm to handle shadow DOM polyfills Shadow DOM for IE is problematic. Shadow DOM is only available in IE as a polyfill. If an element is part of a Shadow DOM (using a polyfill), IE's elementsFromPoint implementation will show the component elements, not necessarily the Web Component root element itself. If the direct parent of the Web Component host element is in this list, then it counts as a direct descendent, and won't be obscured. Note that a potential enhancement to this change is to walk the DOM tree up until an ancestor is found that does not have a shadow root, but that enhancement is not implemented at present.
2019-01-02 09:35:38 -08:00
std::string GetElementHtmlDescription(IHTMLElement* element);
bool HasShadowRoot(void);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
bool IsInline(void);
Making IE driver work with <map> and <area> elements
2019-07-18 15:31:22 -07:00
bool IsImageMap(LocationInfo* location);
Refactoring detection of single-text-node child elements in IE. In IE, a containing text and no background color will not register as a hit target unless the mouse cursor is directly over the text of the element. However, in the case of block elements with children that include text nodes in addition to other elements, if the first text node does not contain any text, the correct behavior is to use the center of the block element for mouse movements. This commit corrects that behavior.
2013-11-07 12:27:41 -05:00
static bool RectHasNonZeroDimensions(IHTMLRect* rect);
Refactored IE driver element click code to all use InputManager class. Previously, WebElement.click() used a different code path than the Advanced User Interactions API. These code paths are now unified for the native events case.
2013-05-09 16:20:57 -04:00
Refactoring detection of single-text-node child elements in IE. In IE, a containing text and no background color will not register as a hit target unless the mouse cursor is directly over the text of the element. However, in the case of block elements with children that include text nodes in addition to other elements, if the first text node does not contain any text, the correct behavior is to use the center of the block element for mouse movements. This commit corrects that behavior.
2013-11-07 12:27:41 -05:00
bool HasFirstChildTextNodeOfMultipleChildren(void);
bool GetTextBoundaries(LocationInfo* text_info);
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
Partially reverted updated obscured element check in IE The updated obscured check introduced in 3.14.0.8 assumed that there was a bug in IE's implementation of elementsFromPoint. This is not the case. The actual bug is that the driver did not take into account elements found outside the DOM tree of the element being interacted with should not be flagged as obscuring the target element if its pointer-events CSS property is "none". This is because while the element may technically be rendered above the target element in the DOM, it does not interfere with attempts to interact with elements below it, since pointer events are not triggered.
2018-10-03 14:11:06 -07:00
bool GetComputedStyle(IHTMLCSSStyleDeclaration** computed_style);
Updating obscured element check for IE The W3C WebDriver Specification dictates that checking for elements being obscured by other elements should rely on calling elementsFromPoint. However, there is a bug in IE's elementsFromPoint implementation. if two sibling elements have the same z-index, the one specified second in the DOM order is usually on top. The exception is if there is a child element that has a specified z-index greater than the ancestor z-index. The IE elementsFromPoint implementation ignores the child element case, so we have to manually look for child elements that may be rendered on top of the element found outside the element DOM tree of the element we are attempting to interact with.
2018-09-18 11:59:39 -07:00
KristianRosenvold: Removed windows carriage returns
2013-01-11 22:18:32 +01:00
std::string element_id_;
CComPtr<IHTMLElement> element_;
HWND containing_window_handle_;
};
} // namespace webdriver
#endif // WEBDRIVER_IE_ELEMENT_H_
Reference in New Issue Copy Permalink