***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
When the in-view centre point contains a floating point, we need to
ensure to convert it to CSS pixels before passing it on to Gecko internals
such as DOMElement.elementsFromPoint and DOMWindowUtils.sendMouseEvent.
For example, with a click target that is a 1x1 square, the in-view
centre point prior to this patch was calculated to (0.5,0.5).
elementsFromPoint will (correctly?) round this coordinate down and
return the paint tree for the DOM element at (0,0) coordinates.
By contrast, sendMouseEvent will click coordinates (1,1) because it
rounds up. To make sure we all speak the same language internally,
we round the centre point down.
Differential Revision: https://phabricator.services.mozilla.com/D8880
--HG--
extra : moz-landing-system : lando
To avoid confusion with the global "window" object we should
avoid using this name as function argument.
Changes for driver.js are left-out and will be done by the
patch on bug 1311041.
--HG--
extra : rebase_source : f15714af3a422476923d096eb8cb837ae474c675
elementsFromPoint will return the top level element of a shadow DOM
and not the elements within. If we are on the top level document we
need to make sure to use the correct rootNode.
MozReview-Commit-ID: ATvCidAFEeM
--HG--
extra : rebase_source : c6c8e20745a64b19cc0d1784044efe4fed4af9bf
There are some places where we have a thing which may not even be a node, and
we end up hardcoding the value of DOCUMENT_NODE there, because
"foo.nodeType == foo.DOCUMENT_NODE" will test true if foo is not a node: both
sides will be undefined.
Remove the legacy key that Marionette uses in addition to the identifier key.
MozReview-Commit-ID: 6IVtLxOJPoS
--HG--
extra : rebase_source : 8c4628d32cdcc7b1b7145b8c7c2660708f3bd20d
To retrieve links via "link text" or "partial link text" the rendered
content of the element has to be used. This can be the case for CSS
transformations like "uppercase".
MozReview-Commit-ID: fxaHEuWnbf
--HG--
extra : rebase_source : d283275a538662e1f199fd5646997f302c4b8ac7
To retrieve links via "link text" or "partial link text" the rendered
content of the element has to be used. This can be the case for CSS
transformations like "uppercase".
MozReview-Commit-ID: fxaHEuWnbf
--HG--
extra : rebase_source : 9336a5ede468046e06f065f401a461dde5848a18
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
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : source : 12fc4dee861c812fd2bd032c63ef17af61800c70
This was done using the following script:
37e3803c7a/processors/chromeutils-import.jsm
MozReview-Commit-ID: 1Nc3XDu0wGl
--HG--
extra : rebase_source : c004a023389f1f6bf3d2f3efe93c13d423b23ccd
Introduces a new function, isMutableFormControl, to the element
module in Marionette that tests if an element is a form control
that can be edited by the user. This replaces the proprietary
UNEDITABLE_INPUTS set used previously.
An editable element is, according to the WebDriver standard, an
element which belongs to the two subcategories of editable elements.
This patch implements the first category of the mutable form controls.
MozReview-Commit-ID: Aix19mq3lcb
--HG--
extra : rebase_source : 1e3d671cd2d3ff618bf2fff3a2d8dadbd82d0540
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
Henrik Skupin
Narcis Beleuzu
Brendan Dahl
Victor Porof
Frederik Braun
Myk Melez
Kris Maglione
Olli Pettay
Andreas Tolfsen
Wambui
Paolo Amadini
David Burns
Boris Zbarsky
Andreea Pavel
Coroiu Cristina
Cameron McCormack
Andrew McCreight
Cosmin Sabou
Brindusan Cristian
Sebastian Hengst