Using only the different unload events to detect a page load is
unreliable because of a possible delay in starting the navigation,
which could be triggered by a slowness of the application.
By using 'beforeunload', an event will be received much earlier,
and the unload timer can be extended to a couple more seconds to
wait for the navigation request to start.
If a website has it's own 'beforeunload' listener registered,
a tab modal dialog will be opened by Firefox, and Marionette
returns from the currently active command immediately to allow
the test to handle the dialog.
MozReview-Commit-ID: 6ZUYtFJSSnz
--HG--
extra : rebase_source : 3f7b9d9d0067ed7c65a3bb8774f0a5ae8bc702c2
Because individual <option> elements are painted and represented in the
DOM when they belong to a <select multiple> list, the center point of
the list might be one of the options.
To take this into account, we perform an inclusive descendant check
(DOMElement.contains) to see if the <option> element is a descendant of
the container <select> element.
In the case the targetted element is the element itself, the test will
still pass since it is an _inclusive_ descendant check. In other words,
containerEl.contains(tree[0]), if tree[0] is equal to containerEl,
will pass.
The relevant specification changes were made in
40abcefd6a.
MozReview-Commit-ID: ORX8zLxQJ
--HG--
extra : rebase_source : 87ca38df6696257d569ef1ffcb888426d1f569af
If the click command triggered a page load, it should not return before
the page has been fully loaded. With this patch we allow an opt-in for
commands to make use of an unload check. It's set to 200ms right now, and
will cancel an ongoing waitForPageLoad() if no page activity is detected.
MozReview-Commit-ID: DWV53sckBS2
--HG--
extra : rebase_source : 1b7905c101b7ebf406e88c73be5d0e069b7342c0
If the click command triggered a page load, it should not return before
the page has been fully loaded. With this patch we allow an opt-in for
commands to make use of an unload check. It's set to 200ms right now, and
will cancel an ongoing waitForPageLoad() if no page activity is detected.
MozReview-Commit-ID: DWV53sckBS2
--HG--
extra : rebase_source : 455e252e85c14b4ca841f02794bf0d33133ef10a
This patch removes the call to element.isVisible when clicking XUL
elements because it does not do anything useful. element.isVisible skips
the Selenium atom.isElementDisplayed check for XUL elements and runs a
few web content/viewport centric tests that always pass in XUL.
It also splits the chrome click out to a separate function to avoid a
few if-conditions.
MozReview-Commit-ID: EkcwT77ku3C
--HG--
extra : rebase_source : ee5e8148934ec008cda996610c20a826f86412af
The window reference may have been discarded as a result of interaction.
For example, this may happen when clicking a button that deletes the
host <iframe> element containing the child window. In this case, the
WindowProxy will set its closed property to true, to indicate that the
browsing context has been discarded.
We only want to flush the event loop of windows that exist, and so we
return early from interaction.flushEventLoop if the window has been
closed.
MozReview-Commit-ID: LtTHQRudKvk
--HG--
extra : rebase_source : e4133ddeed9e89e38fba6e9b8f17544a3546f7eb
The WebDriver specification changed recently to introduce a new
'element click intercepted' error that is returned if the high-level
Element Click command attempts an element that is obscured by another
(the other element's z-index, or order in the paint tree, is higher).
This patch introduces the notion of 'container elements', which is an
element's context. For example, an <option> element's container element
or context is the nearest ancestral <select> or <datalist> element.
It also makes a distinction between an element being pointer-interactable
and merely being in-view. This is important since an element may be in
view but not pointer-interactable (i.e. clicking its centre coordinates
might be intercepted), and we do not want to wait for an element to
become pointer-interactable after scrolling it into view if it is indeed
obscured.
MozReview-Commit-ID: 8dqGZP6UyOo
--HG--
extra : rebase_source : 68f1f7ee922ab8ed6acd92d3f89d6887b23ae801
This renames the ElementNotVisibleError to ElementNotInteractableError,
and adds a new ElementClickInterceptedError.
MozReview-Commit-ID: 6cjVghUCvyv
--HG--
extra : rebase_source : 3f2105c1f631ac4776e231bb6c88a00e26f1ae6c
Checking for general interactability will also consider keyboard
interactability, which has not yet been implemented. On interacting with
an element by clicking, we should only test for pointer interactability.
MozReview-Commit-ID: BUCs7zHppRm
--HG--
extra : rebase_source : 2053a49ee4bcb291299568902e9ac25cc747bc5e
This removes the need to use a CPOW when sending keys to <input type=file>
elements. It was previously not possible to constructo File objects in
privileged content space, but this now appears fixed.
MozReview-Commit-ID: 8XOVsDdypwC
--HG--
extra : rebase_source : 8d4329c4c6a64ac717fc5d54dc42c8eb136f5e7f
This patch introduces support for clicking on <select> and <select
multiple> elements to Marionette. As <select> elements, especially
<select multiple>, are operating system level concepts usually implemented
with native widget sets, this patch takes the approach of dispatching
generated events.
MozReview-Commit-ID: 9kwOva43AOL
--HG--
extra : rebase_source : dde090ed9487e593bc16f8a7e12365b97ada9735
"Check" is a fine word but with functions which primary purpose is to
throw an error internally we should use "assert" to make the reprecussions
of using them crystal clear.
MozReview-Commit-ID: Kef4R8y8fiV
--HG--
extra : rebase_source : eb22beb7a33e593f34b3d24ecdaaa7f99d8e5f87
Some of the element interactability- and visibility checks were previously
done when interaction.clickElement was called, and not as part of the
resolution of the returned promise. This could have caused a potential
race condition.
MozReview-Commit-ID: 691V86B4k5w
--HG--
extra : rebase_source : 7a6951d9c29aa5fa3eb3852d3d6d33e65f7d72c4
We want to redo the element interactability calculation after scrolling.
Determining if an element is not visible by the old location would
be wrong.
MozReview-Commit-ID: KGaPVmgcqSX
--HG--
extra : rebase_source : 12ac51e5c9947da1082351c4e382cfc95ea8f843
The if-condition in the specification compatible interactability check
for interaction.clickElement is wrong. It should scroll an element into
view when it is _not_ visible. If it is visible it does not matter.
MozReview-Commit-ID: 2n34QddDkQv
--HG--
extra : rebase_source : efe079de9a1fa930ea2f3d9d8fff59fc9a4e269b
Implements the WebDriver pointer-interactability algorithm described in
http://w3c.github.io/webdriver/webdriver-spec.html#dfn-interactable-element.
The specification compatible behaviour is enabled only when the client
requests the capability specificationLevel >= 0.
MozReview-Commit-ID: BP60SGj49OW
--HG--
extra : rebase_source : d84d38510e28ab5e0debce2051e336e1fd3f0f86
Implements the WebDriver pointer-interactability algorithm described in
http://w3c.github.io/webdriver/webdriver-spec.html#dfn-interactable-element.
The specification compatible behaviour is enabled only when the client
requests the capability specificationLevel >= 0.
MozReview-Commit-ID: BP60SGj49OW
--HG--
extra : rebase_source : 357accaa38b44704fcaf839aa50e1e29af0b3f99
