Introduces two new functions called element.isEditingHost, for
determining if an element is content-editable or part of a document
in design mode, and element.isEditable, which implements the
WebDriver-defined concept of what it means for an element to be editable.
WebDriver consideres an element editable if it is not read-only or
disabled, and one of the following conditions are met:
- It is a <textarea> element.
- It is an element that is not of the checkbox, radio, hidden,
submit, button, or image types.
- It is content-editable.
- It belongs to a document in design mode.
MozReview-Commit-ID: 6U71uSUNwoI
--HG--
extra : rebase_source : c5702362d5be531b2e5b764fac13bb9db9f20f23
Adds a new function called element.isDisabled to test for disabledness.
An element is only considered disabled if it is indeed an element
that can be disabled, for example that it is a <button>, <input>,
<select>, <textarea>, <optgroup>, or <option> element. All other
elements are not disabled.
In nested trees the disabledness state of a containing element
affects child elements, without this being refelected in the child
element's content IDL attribute. In the following example, the
<option> element is disabled:
<select disabled>
<option>foo
</select>
Similarly:
<select>
<optgroup disabled>
<option>bar
</optgroup>
</select>
This means we have to traverse the tree to find the closest ancestral
parent element, whether it is <optgroup> or <select>, and inspect
its state before we can be sure the element in question is not disabled.
MozReview-Commit-ID: 578zLNj7nXK
--HG--
extra : rebase_source : fb8f4dc519a57a8fb4849a098f1e06f79aa02c9f
Introduces new function for testing whether an element is read-only.
This content IDL attribute only applies to <input> and <textarea>
elements.
MozReview-Commit-ID: 1YLizKUYMU6
--HG--
extra : rebase_source : 2d7dcd34d20cf0dd2f0e0087b28e5eeebfa72fad
element.findClosest is a more generalised version of findAncestralElement,
which is limited to a list of element tag names. By using
element.findClosest and CSS matching we also avoid a redundant iteration.
MozReview-Commit-ID: 32QwmkwiGf5
--HG--
extra : rebase_source : 5197971bd950cd0d90514a12bacb4642779a9090
Introduces a new function, element.findClosest, that finds the
closest parent node by a CSS selector expression. This is useful to
find arbitrary elements in the tree above us and is quite possibly
reusable for element.getContainer.
MozReview-Commit-ID: 8rBEepmDdPm
--HG--
extra : rebase_source : 3055d23ce7aeba355de93fdeff52eb4ffdffbc24
It is a bug in element.getContainer that <optgroup> is not considered
when locating the containing context element, <select>. <optgroup>
is also a child element of <select> on the same level as <option>.
MozReview-Commit-ID: 2GJJrRuY5Th
--HG--
extra : rebase_source : 2bfabe6f79bc0d6d473657ef34cded04c51857a3
There is an unused nsITimer instance in element.Store#timer that
this patch safely removes.
MozReview-Commit-ID: APvPsXfHUk9
--HG--
extra : rebase_source : f936abcb20d42c0eb27cfdee62d461d276cc2e5c
When looking up the parent of <html> using an XPath parent expression
such as "..", the nodeType of the returned HTMLDocument will be 9
(DOCUMENT_NODE). <html> is a valid web element and we should be
able to serialise and return it to the user.
It is worth noting that other WebDriver implementations fail this
test because they fail on the nodeType check.
MozReview-Commit-ID: 4FMJEd8B4PZ
--HG--
extra : rebase_source : 24e7cb9da64cde0f133a09781c595b23f919ed59
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
As long as bug 1413493 has not been fixed the <tr> nodes will not be part
of the element tree. To workaround this problem we could use the first
found cell of the given row to check for visibility.
MozReview-Commit-ID: 57nuvxYrSMg
--HG--
extra : rebase_source : 8a27105bf3a0ff9d226869fe0fa6b70c89dc4c0e
Because as long as bug 1089326 is not fixed child nodes of <button>
are not part of the element tree. As such the button has to be returned
as container for any of those nodes.
MozReview-Commit-ID: Jq6B9Kn7VAf
--HG--
extra : rebase_source : 8c89322d14b14bc1409f36de6cf897c2635a5603
If the node variable is an object that is not null, and nodeType is
not an own property of it, node.nodeType === node.ELEMENT_NODE might be
evaluated as undefined === undefined if ELEMENT_NODE is also missing.
This will pass the condition, which is an unintended consequence.
To remedy this, we first check that nodeType indeed exists on node
before proceding.
MozReview-Commit-ID: G0eaRvwm5mv
--HG--
extra : rebase_source : 8c08e0363f26095cf672d2b11699431b1fb4ef9f
This drops the now-superfluous element.isSVGElement. SVG elements
are matched with element.isDOMElement because there is no special
need to distinguish them from other elements, apart from chrome elements.
MozReview-Commit-ID: 3AgEtyaAsPU
--HG--
extra : rebase_source : 7ec52aa9a7b7404eff5b6daf8ebe8259f06265da
This patch makes element.isDOMElement match any non-XUL element,
meaning it will henceforth match both SVG elements as well as any
custom XML namespaced element.
In the bug 1410796, Marionette does find the element, but is unable
to add it to the known web element store. This is a result of the
changes made in bug 1400256, where I introduced a set of functions
for element type recognition needed for determining which web
element abstraction to use for an element.
We use element.isDOMElement to distinguish content elements from chrome
elements, and this change consequently makes element.isSVGElement
superfluous.
MozReview-Commit-ID: AkEHm6zroKz
--HG--
extra : rebase_source : c6f101e12839241f60c8c1b3908df3a3e4a89a51
For user input we will want to return the appropriate invalid
argument error. For internal input using TypeError is fine.
MozReview-Commit-ID: AlOnZuhaczN
--HG--
extra : rebase_source : f16aa13b6fc53da6261594dab0c9df34d6c3df6e
These functions currently return sequences or arrays of elements, which
wastes cycles and memory because we spend time constructing these data
collections in cases where we only need the first element. This is
the case for WebDriver:FindElement and WebDriver:FindElementFromElement.
This patch changes the Marionette element retrieval functions to
consistently provide iterators instead of sequences when looking
up elements. Making them generator functions means the iterable
can be expanded using [...iterable] when necessary.
MozReview-Commit-ID: FZbKLuRWqgA
--HG--
extra : rebase_source : 1e7dc8c614004444f8b2476cb1a136ed36943374
For user input we will want to return the appropriate invalid
argument error. For internal input using TypeError is fine.
MozReview-Commit-ID: AlOnZuhaczN
--HG--
extra : rebase_source : 57992fc62c08736cb24f7ee229a4c8930751e068
Remove element.isWebElementReference in favour of
WebElement.isReference.
MozReview-Commit-ID: IOqx7XMUfCu
--HG--
extra : rebase_source : e25b0f709d3c11a6a26b937e9a72ca861fe34730
This patch introduces a series of web element abstraction types for
representing web element references.
Adds a series of new types for representing web element references
in Marionette: ChromeWebElement, ContentWebElement, ContentWebFrame,
and ContentWebWindow. The last three are direct representations of
web element, web frame, and web window definitions described in the
Webdriver specification. The first is a custom Marionette type as
we also support retrieving XUL elements from chrome space and must
be considered proprietary.
Each of the classes extend the WebElement abstract type, which is
the primary entry point when unmarshaling JSON input from the client.
Based on the characteristics of the JSON Object, one of the different
concrete types will be constructed.
The purpose of this change is to make marshaling of elements and
WindowProxies easier, both when we receive web element reference
objects from clients and when transporting them over IPC internally.
The WebElement.fromUUID function should be considered a temporary
workaround until we have fixed the current Marionette clients to send
web element reference JSON Objects as input, instead of plain {id:
<uuid>, …} fields.
MozReview-Commit-ID: FGcRq5H1Tzp
--HG--
extra : rebase_source : fe82087e8935adb519e2934fc37f1d46c21d9187
Introduces new element.isElement shorthand API for identifying DOM-,
SVG-, and XUL elements.
It is the equivalent of this:
if (element.isDOMElement(el) ||
element.isSVGElement(el) ||
element.isXULElement(el)) {
// ...
}
MozReview-Commit-ID: H8MDkP5bQmW
--HG--
extra : rebase_source : 6bef09999e47b178614e4bd307266b4449f39901
In addition to tell DOM- and XUL elements apart we will in the
future need to identify WindowProxies because WebDriver expects
there to be a separate "web window" serialisation for these.
Telling if an abritrary object is a WindowProxy is tricky but we
check if its node.toString is callable, that it returns "[object
Window"], and finally that its "self" attribute is itself. This is
not perfect, but good enough for now.
MozReview-Commit-ID: 6FLOa3qYLPP
--HG--
extra : rebase_source : 27d25d97facf73761a1600e88d938eb76b3bc005
Introduces a new element.isDOMElement function, similar to isXULElement,
for checking whether an element is a DOM element.
It follows the same formula as isXULElement by first testing if the
element is an object so we know we can accesss node.namespaceURI
and node.nodeType without causing a JS error.
MozReview-Commit-ID: 6Mlo33vu5LG
--HG--
extra : rebase_source : 547a2fc5bc0051e3bb51e14add4f57d1ff7972b9
Fixes isXULElement to recognise XBL elements, such as <xbl:framebox>.
Also tightens up the input checks so that arbitrary objects can be
tested, as checking node.namespaceURI directly could cause a JS error
if node is not an object. Before checking the namespace we also ensure
it's an element node so that text- and comment nodes are not picked up.
This patch also introduces tests, which were sorely missing.
MozReview-Commit-ID: 8LNF1z3X1gP
--HG--
extra : rebase_source : ffacc5b1336b35624aaf0534101ce5c3fbdeaa95
The WebDriver:FindElement command returned an array of elements when
looking up anonymous elements. This patch rectifies the behaviour
so that only a single element is returned.
It introduces a new helper function called element.findAnonymousNodes,
akin to similar helper functions for other strategies. This function
returns an iterator of anonymous nodes so that WebDriver:FindElements
(plural) and WebDriver:FindElement (singular) can share the same
code path.
MozReview-Commit-ID: 3IqPyAIZHtf
--HG--
extra : rebase_source : ceffd2b3dfe885b98ae31905f290ab9d95ef26c0
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
The element.isStale function does not take into account the current
browsing context when checking an element’s staleness. This means,
for example, that an element in an <iframe> that gets retrieved, will
still be considered valid for as long as its associated document lives.
In WebDriver the expected behaviour is for the element reference to
only be valid for the current browsing context, meaning retrieving
the element reference when another browsing context is chosen should
return a stale element error.
Fixes: https://github.com/mozilla/geckodriver/issues/934
MozReview-Commit-ID: JpQVt78u5AN
This patch moves the "timeout" and "interval" positional arguments
on PollPromise to an options dictionary.
In the following code example it is hard to know which argument means
what because they are not named:
new PollPromise(resolve => resolve(), 100, 100);
Named arguments can be achieved in JavaScript using option
dictionaries, and this patch changes the input PollPromise takes so
that the above example looks like this:
new PollPromise(resolve => resolve(), {timeout: 100, interval: 100};
This plays especially well with code in testing/marionette/element.js
as we already have named arguments that we can pass directly in through
an object literal, making the code more readable and more compact:
let timeout = 42;
new PollPromise(resolve => resolve(), {timeout});
MozReview-Commit-ID: GFWNGQAeWk1
--HG--
extra : rebase_source : 296843053e72bd07463a3018b06782f0dcc4828a
In formalising our synchronisation module, this renames wait.until
to PollPromise. It is a specialisation of a promise, just like
TimedPromise, that poll-waits a condition for a given amount of time
before either resolving (passing) or rejecting (failing) the poll-wait.
Also fix and improve documentation.
MozReview-Commit-ID: AcP3C1qCgKA
--HG--
extra : rebase_source : d17bb3be0819b0ce9de55d44741836fc00b10f46
testing/marionette/wait.js originally contained a utility for
poll-waiting on a condition. The module has since been expanded to
also include TimedPromise, which is a specialisation of Promise that
is rejected after a duration.
The latter is not a wait utility but a synchronisation primitive.
This terminology also covers the first, and this change renames the
wait module to sync.
MozReview-Commit-ID: Fd3LqfpiEaU
--HG--
rename : testing/marionette/wait.js => testing/marionette/sync.js
extra : rebase_source : f48ff62ca2589ab0ce4a2f3d134d392e6f0be015
This patch moves the "timeout" and "interval" positional arguments
on PollPromise to an options dictionary.
In the following code example it is hard to know which argument means
what because they are not named:
new PollPromise(resolve => resolve(), 100, 100);
Named arguments can be achieved in JavaScript using option
dictionaries, and this patch changes the input PollPromise takes so
that the above example looks like this:
new PollPromise(resolve => resolve(), {timeout: 100, interval: 100};
This plays especially well with code in testing/marionette/element.js
as we already have named arguments that we can pass directly in through
an object literal, making the code more readable and more compact:
let timeout = 42;
new PollPromise(resolve => resolve(), {timeout});
MozReview-Commit-ID: GFWNGQAeWk1
--HG--
extra : rebase_source : 06e558129f1e0acf3fbf8b6ca99c2407320b8e61
Now that we have selective imports through Cu.import we can give
wait.until a more descriptive name that matches TimedPromise.
This patch renames the wait.until utility to PollPromise.
MozReview-Commit-ID: 9gsvAV27mMl
--HG--
extra : rebase_source : ea98d63013d709d52ce234446404233d9dbe572e
testing/marionette/wait.js originally contained a utility for
poll-waiting on a condition. The module has since been expanded to
also include TimedPromise, which is a specialisation of Promise that
is rejected after a duration.
The latter is not a wait utility but a synchronisation primitive.
This terminology also covers the first, and this change renames the
wait module to sync.
MozReview-Commit-ID: Fd3LqfpiEaU
--HG--
rename : testing/marionette/wait.js => testing/marionette/sync.js
extra : rebase_source : 5e22ec5e26b5405c928ab26734a8d2ddc5d43785
With newer Selenium atoms which do not conflate attributes and
properties, the retrieval via getElementAttribute will fail. By
retrieving it directly as property will fix it.
MozReview-Commit-ID: CFy3JZDeUWq
--HG--
extra : rebase_source : ed3a358f52b7cd54f3c5dda037fddaa93173e3b6
Andreas Tolfsen
Henrik Skupin
Sebastian Hengst