This patch fixes remaining bugs in Marionette for uploading
files via "element_send_keys", and also adds support for
multiple file uploads.
It also adds Wdspec tests to proof the latest changes to
the WebDriver specification.
MozReview-Commit-ID: 2OKGNxMvyMr
--HG--
extra : rebase_source : c5c9e9bd8c0c0bf81e7920299f56fa5006b1f8c5
Calling Cu.importGlobalProperties immediately defines the import
properties and any prototypes that they require. Aside from CPU
overhead, this also tends to consume a lot of memory, especially
for objects with complex prototypes. And it does this once for
every global you call it in. This is especially a problem for
content processes, since we get this memory overhead in each and
every content process.
This patch moves Marionette to use the new
XPCOMUtils.defineLazyGlobalGetters so that symbols are constructed
only when actually needed.
MozReview-Commit-ID: 3RYWTcdO7FM
--HG--
extra : rebase_source : 0c450c8900e5de5446796b34ae4ab6bdf0fe9118
According to the WebDriver standard the Element Send Keys command
should not run the unfocussing steps. Not blurring the element
causes the DOM "change" event not to fire, but the specification
only expects the "input" event to fire.
The standard does, however, expect the Element Clear command to
run the unfocussing steps and to blur the element for historical reasons.
MozReview-Commit-ID: FHD1whho0jT
--HG--
extra : rebase_source : a03f2befd3373a0e5a167deca012540887546a4b
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <![CDATA[, """ or '''. The first two
cover comments, the third one covers JS, the fourth covers JS embedded
in XUL, and the final two cover JS embedded in Python. This also
applies if the removed line was the first line of the file.
It covers the pattern matching cases like "var {classes: Cc,
interfaces: Ci, utils: Cu, results: Cr} = Components;". It'll remove
the entire thing if they are all either Ci, Cr, Cc or Cu, or it will
remove the appropriate ones and leave the residue behind. If there's
only one behind, then it will turn it into a normal, non-pattern
matching variable definition. (For instance, "const { classes: Cc,
Constructor: CC, interfaces: Ci, utils: Cu } = Components" becomes
"const CC = Components.Constructor".)
MozReview-Commit-ID: DeSHcClQ7cG
--HG--
extra : rebase_source : d9c41878036c1ef7766ef5e91a7005025bc1d72b
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
extra : intermediate-source : 34c999fa006bffe8705cf50c54708aa21a962e62
extra : histedit_source : b2be2c5e5d226e6c347312456a6ae339c1e634b0
Bug 1432864 introduced a regression where the element conditions
for moving the caret to the end of the textual input were wrong.
Apparently if conditions are hard.
MozReview-Commit-ID: KlRv6sCroXW
--HG--
extra : rebase_source : d649bc2c63d616f77bf7cebdb72875047a57b502
Focussing the element changes the selection range.
MozReview-Commit-ID: JW68aZupkly
--HG--
extra : rebase_source : 61a6129d8d51ceec44485271bd0d6fa54fc7f357
A couple of commands were not running the appropriate unfocussing
steps as the WebDriver standards says they should.
MozReview-Commit-ID: FyuRvkct19m
--HG--
extra : rebase_source : fe37727126a6907f6182d166a035b4f368118df9
Instead of generating custom focus events when interacting with elements,
we can run the HTMLElement.focus() function will do the correct thing.
Before this patch we only simulated focus events, whereas this
patch will actually focus the element.
MozReview-Commit-ID: IoBV2ngqOA5
--HG--
extra : rebase_source : c133a8ac7fc91dfa373a9d8adbc3f30d2441c46d
Renames the interaction.focusElement, which also happened to move
the caret in textual form controls, to interaction.moveCaretToEnd,
focussed solely on moving the caret. It doesn't make sense to
coalesce these two operations into one function.
MozReview-Commit-ID: 2QxV8FllW8J
--HG--
extra : rebase_source : f95973c3bd5759d4b60467f88720ea66c0511873
When clearing an element using the WebDriver Element Clear command,
the DOM change event should be fired.
MozReview-Commit-ID: 94iG8bsRe4S
--HG--
extra : rebase_source : db67b681aabae64c463e3591ee43c7fd0995b3af
This patch checks that the element satisfies its form control
constraints, as well as being empty, before deciding not to clear
the element. This will make it possible to clear elements that
have invalid input.
The "clear a resettable element" algorithm is missing a check of
the <input> element's ValidityState. WebDriver:ElementClear has
a subtle bug that only manifests in Gecko because Blink rejects
invalid key input to validation fields such as <input type=number>,
but Gecko does not.
The value property of <input type=number> will not be updated unless
the input is actually valid, which means the first step of the algorithm
will pass irregardless of whether the user has actually modified it.
MozReview-Commit-ID: C2M3Fl1iKx6
--HG--
extra : rebase_source : 8e5698cf8adab4361d16ada403858d0703861d9a
This implements the remote end steps for the Element Clear command
from WebDriver in Marionette.
The WPT test webdriver/tests/interaction/element_clear.py was deleted
because it tested a previous definition of the Element Clear command
and many of its tests were either incorrect or replaced by the new tests.
MozReview-Commit-ID: C2xmIlhSAdW
--HG--
extra : rebase_source : 8eddcee78450a8c7d10cf9f648bb1baabdac4ff1
When WebDriver:ElementClick clicks an <option disabled> element,
its selectedness state should according to a new specification
change proposed not change:
https://github.com/w3c/webdriver/pull/1189
This patch provides tests for the specification change.
MozReview-Commit-ID: EXG98LjgB7d
--HG--
extra : rebase_source : d9e5b31dbd869c8151d85eb2b5bb8ba94a378a52
Enables webdriver spec keyboard interactability tests for 'Element Send Keys'
by default by re-using the same capability 'moz:webdriverClick' from
'Element Click'. It can be disabled by turning off this preference.
Also various webplatform tests for webdriver spec have been added which
cover both the scroll into view action, and keyboard interactability check.
Existing Marionette unit tests will be run in both modes, until we can
get rid of the legacy mode.
MozReview-Commit-ID: dFB8sQ6CN5
--HG--
extra : rebase_source : 9f6a3c3e42f779f039f61d0b239f9f5925ecdcf5
Each call to sendKeysToElement should go through the interaction
module, and never by directly calling event.sendKeysToElement. This
will make sure that keyboard interactability checks will always be
performed, even for chrome scope like alerts or modal dialogs.
MozReview-Commit-ID: GoDKjMsNZsq
--HG--
extra : rebase_source : c305c748e68e60abd01dab37d00a7e3aff7d3d64
If the DOM click event does not fire, which currently happens in
this edge case where Firefox does not bubble the click event up
to <body>, interaction.flushEventLoop will hang forever.
This is believed to be a bug in Gecko, but it is probably safer to
use a TimedPromise here in case anything else bad were to happen.
Thanks-to: Alexei Barantsev <barancev@gmail.com>
MozReview-Commit-ID: KZBdR8zcfJb
--HG--
extra : rebase_source : aba0c4c810a703877d858fa6f4398ad960ece0d1
This changes interaction.flushEventLoop from relying on the beforeunload
DOM event to determine when to bail in case the document navigates.
Instead, it now relies on the unload event which should not affect
bfcache.
It also changes flushEventLoop to append a click event listener to
the targetted element's container element. Because this event will
be added last, the intention is that all preceding click evens will
have had time to fire and propagate before our listener spins the
event loop through setTimeout once.
Our listeners are added using the privileged mozSystemGroup option so
that a potential invocation of EventTarget.stopImmediatePropagation
does not prevent our listener from firing.
MozReview-Commit-ID: 2Ehxwg2p6Fo
--HG--
extra : rebase_source : 767bc955ba49152ff501ee8ff9c856fe204b25f4
Pretty-printing an object belongs more naturally to the new format module.
MozReview-Commit-ID: AfXLMPAT5ar
--HG--
extra : rebase_source : 1074febec66df49745256fc9cd04b0fecd293919
Splits interaction.isElementSelected into two parts: one checking
whether the element DOM properties are selected/checked, and the
other checking accessibility. This so this so that the selectedness
can be unit tested, as we do not have the capability of standing
up accessibility in the xpcshell tests.
The second part of this change moves us away from atom.isElementSelected
in favour of a specification conforming implementation in Marionette.
This is a word-by-word implementation of the Is Element Selected
command from WebDriver.
MozReview-Commit-ID: 93WDKbPcEIB
pprint is currently exposed twice: once on the error namespace and once
separately. We only want to expose it once, and since there are only a
handful "error.pprint" usages left, we can go ahead and make this change.
When we move transition to use "require" in the future, like devtools
does, it will be possible to use both "error.pprint" and "pprint" styles
without export duplication.
MozReview-Commit-ID: CAnPDWn9Vr7
--HG--
extra : rebase_source : 05a05460d710eb96fa7b20cb94477be0282809de
It turns out that Node.isConnected (described in
https://dom.spec.whatwg.org/#dom-node-isconnected) handles an element’s
shadow root, which element.isDisconnected tries to replicate.
element.isDisconnected and element.isStale are both long and error-prone
and can be removed entirely in favour of this web platform API.
The relevant change to the WebDriver specification landed in
32a477b023.
MozReview-Commit-ID: 5Q0gWLvw8KL
--HG--
extra : rebase_source : 773ab302df27cf11be6079f918a48d3730ceb5c1
The element click functions in testing/marionette/interaction.js are
generator functions using "yield". This patch converts them to async
functions.
MozReview-Commit-ID: 4A4cTaY619w
Marionette deselects <option>s if they are already selected in <select
multiple>, but it should not deselect them if they are in a dropdown
<select>.
MozReview-Commit-ID: 9CHfYrGn7xR
--HG--
extra : rebase_source : f2357c8b111a0296844b8eb594cfb13e8799c3a0
Marionette throws a TypeError when the element is not an <option>,
and we should use the same error type when a XUL element is passed.
MozReview-Commit-ID: 3p3wPcW621f
--HG--
extra : rebase_source : dd5147d98ce68e664d0782949a760f499f3fe24a
Throw a better error message when the wrong element type is passed to
interaction.selectOption.
MozReview-Commit-ID: G1NIZ25umm2
--HG--
extra : rebase_source : 55389d965c253dc3f1718e627f5c3a0c4f16fb84
Various fixes to make the generated API documentation from
testing/marionette somewhat easier to read.
MozReview-Commit-ID: F9duuQoOYBt
--HG--
extra : rebase_source : 3ade69773ceba42826aedef05b1371240b51cf82
Instead of importing everything from the testing/marionette/error.js
module into the global scope, we need to be selective about what symbols
we want.
MozReview-Commit-ID: HZDAS0bs0GD
--HG--
extra : rebase_source : 14a300bb2cedc0716168d50846755a6faed83012
When we enable "dom.forms.datetime", <input type=date> and <input type=time>
are displayed as multi-field text box, where the fields are ordered depending
on locale. To avoid too much overhead, instead of synthesising each key event,
we set the element's value property and fire the corresponding events to
emulate user interaction.
MozReview-Commit-ID: Ao6ip61CNT6
--HG--
extra : rebase_source : f03d9c5d2e2540e6c2189b542d9270be5fb63919
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
