Using the {foo = null} = {} shorthand to generate default values exposed
as function scope variables is more readable, and arguably somewhat safer,
than the current approach.
MozReview-Commit-ID: Lxn0fpBSR3a
--HG--
extra : rebase_source : 63fa829657d726e8987a77b5add817a3b7d0b7d3
Whilst try...catch (e if foo) { ... } is a very nice construct, it has
not been standardised and we should avoid using non-web platform features.
MozReview-Commit-ID: 9qzHtBdlPfw
--HG--
extra : rebase_source : be27a3d647eba2d48721c77dabe12ca13278bda9
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
The InvalidCookieDomainError type is missing a status lookup key in
testing/marionette/error.js. This adds "invalid cookie domain" as a
reverse lookup for the type.
MozReview-Commit-ID: 69hkk28axtt
--HG--
extra : rebase_source : 19628df79d89f7fbaf821cc1847e1be241ff56af
JavaScript errors that arise from the Marionette implementation are
currently wrapped as WebDriverErrors. A WebDriverError is encoded with
a "webdriver error" error code, which officially does not exist in the
WebDriver specification.
To distinguish WebDriver errors from programming errors of Marionette,
this changes them to be encoded as UnknownErrors (error code
"unknown error"). This will make stacktraces coming from clients
easier to read, since it is clear that the error is not caught by the
WebDriverError-catchall.
MozReview-Commit-ID: A5HejTOgOp8
--HG--
extra : rebase_source : 7bd4f539954dd11973b2bd16c1bf4f4ea7b4a4d7
This change makes it possible to click elements that has its
pointer-events style property set to "none".
If an element has its style property pointer-events set to "none",
the element in view test will fail due to document.elementsFromPoint
excluding it due to non-interactability. This is only a problem when
checking if the element is inside the viewport, and not when actually
performing interaction with the element.
The relevant specification change is
ba6ee925b5.
MozReview-Commit-ID: JwZB6fm7P9A
--HG--
extra : rebase_source : 18ddf7955c7e0bc6d1d7f798aebc6e09799a99ca
Add preliminary support for returning unexpected alert open errors when
calling commands that require it according to the WebDriver standard.
Also fixes a faulty test that seems to believe it is fine to click an
element whilst an alert is present.
Further work needs to be done on user prompts, asserts, and the handler
for user prompts in https://bugzilla.mozilla.org/show_bug.cgi?id=1264259.
MozReview-Commit-ID: BiWURoQECji
--HG--
extra : rebase_source : caa1506a0e972c7ad0da2d31993fb0b8ecc1ee17
When passing a DOM element that is an HTML element to error.pprint,
it will get pretty-printed with its ID and class properties.
This helps to identify elements when one is obscuring the other when
clicking. For example, the error message
Element <input id="foo"> is obscured by <input id="bar">
is nicer than the old error message
Element [object HTMLElement] {} is obscured by [object HTMLElement] {}
MozReview-Commit-ID: 8U2Lo8V4lmv
--HG--
extra : rebase_source : a0a0176f1fed9786da6260e27d28c23c8eb2a944
This renames the ElementNotVisibleError to ElementNotInteractableError,
and adds a new ElementClickInterceptedError.
MozReview-Commit-ID: 6cjVghUCvyv
--HG--
extra : rebase_source : 3f2105c1f631ac4776e231bb6c88a00e26f1ae6c
Since bug 1326534 we have discarded the original stacktrace from errors
originating inside Marionette. This was due to faulty logic when
attempting to generate a new stacktrace when it was missing from a
propagated error.
This change simplifies WebDriver errors by making use of Error
inheritance. The WebDriver error specific functions error.toJson and
error.fromJson has additionally been moved to WebDriverError.
MozReview-Commit-ID: C3Ns0H01LyG
--HG--
extra : rebase_source : 0c705054dae8c0647500bb90e9b970cc57e712c4
To avoid errors from being needlessly constructed on starting the
Marionette server, this changes testing/marionette/error.js to use a
static lookup table for error status codes.
This also provides some added security since individual custom errors
may have specific constructor logic that would cause an error to throw
an error if the correct arguments were not provided, and we cannot
guarantee that we provide the right ones generically when loading in
the error module.
MozReview-Commit-ID: 1sejpNzsjJp
--HG--
extra : rebase_source : 1d57c56675d5a374bc97c463898e7b5ed77ef7b8
When we currently create new WebDriver errors we throw away the stacktrace
generated by `WebDriverError`'s prototype, `Error`. This change stores
the stacktrace, which will cause it to be serialised and returned to
the client.
This change is not as valuable as storing the stacktraces of internal
errors, but brings symmetry to our error handling and may be useful if
only to navigate to the source of an error.
MozReview-Commit-ID: LCFMwKxxcTp
--HG--
extra : rebase_source : 56947805f29000a64c2daef0fd774ea90330c09e
The `stack` argument to `WebDriverError` has never been in use. Following
the API of the `Error` prototype, this changes its constructor to take
one argument which can either be a string of an `Error`.
When internal errors are thrown in Marionette, they are usually
wrapped in `WebDriverError` but we currently lose track of its stack.
This preserves the wrapped error's stacktrace by setting the `stack`
property. Practice have found that they are very useful to return to
the client, as they are currently only printed to stdout.
MozReview-Commit-ID: 9sTdP4TntIc
--HG--
extra : rebase_source : f14197a1c8700215ce3d0edc7078c9f568b80ec4
Many tests that result in throwing errors, amongst those many type-
and platform checks, are repeated throughout the Marionette code base.
This patch centralises the most common of these, typically reducing
consumer calls from three to one line.
Example usage:
assert.defined(cmd.parameters.value);
assert.postiveInteger(cmd.parameters.value,
error.pprint`Expected 'value' (${value}) to be a signed integer`);
// InvalidArgumentError: Expected 'value' ([object Object] {"foo": "bar"}) to be a positive integer
MozReview-Commit-ID: BHOaDazeGer
--HG--
extra : rebase_source : 1d35c10e29d4fd536829e9714ae65bcd14ad21f8
It turns out that certain objects such as a DOMRectList have peculiarities
that cause string comparison to throw. This is normally not a problem
as error.isError is usually passed JSON serialisable data. But when it
is not, this try condition helps diagnose problems.
MozReview-Commit-ID: BLNSziwfxXs
--HG--
extra : rebase_source : 8bad973a20d8b69fa27f5de66e4ea287d4bcddcd
In order to achieve WebDriver parity, Marionette needs the ability to
evaluate scripts in content space with lasting side-effects. This means
that state modifications should affect behaviour and state of the browsing
context, and such transgress the boundaries of the sandbox.
This patch brings a new script evaluation module that is shared between
code in chrome- and content space. This brings the number of unique
script evaluation implementations in Marionette down from six to one.
evaluate.sandbox provides the main entry-point for execution. It is
compatible with existing Marionette uses of Execute Script and Execute
Async Script commands in Mozilla clients, but also provides a new stateful
sandbox for evaluation that should have lasting side-effects.
It is not expected that Mozilla clients, such as testing/marionette/client
and the Node.js client in Gaia, should have to change as a consequence
of this change.
A substantial change to the script's runtime environment is that many
globals that previously existed are now only exposed whenever needed.
This means for example that Simple Test harness functionality (waitFor,
ok, isnot, is, &c.) is only available when using a sandbox augmented
with a Simple Test harness adapter.
Conversely, this patch does not expose marionetteScriptFinished as a
callback to asynchronous scripts for sandboxes which sandboxName parameter
is undefined, because this is what determines if the script should be
evaluated under WebDriver conformance constraints. In all other cases
where sandboxName _is_ defined, the traditional marionetteScriptFinished
et al. runtime environment is preserved.
MozReview-Commit-ID: 8FZ6rNVImuC
In order to achieve WebDriver parity, Marionette needs the ability to
evaluate scripts in content space with lasting side-effects. This means
that state modifications should affect behaviour and state of the browsing
context, and such transgress the boundaries of the sandbox.
This patch brings a new script evaluation module that is shared between
code in chrome- and content space. This brings the number of unique
script evaluation implementations in Marionette down from six to one.
evaluate.sandbox provides the main entry-point for execution. It is
compatible with existing Marionette uses of Execute Script and Execute
Async Script commands in Mozilla clients, but also provides a new stateful
sandbox for evaluation that should have lasting side-effects.
It is not expected that Mozilla clients, such as testing/marionette/client
and the Node.js client in Gaia, should have to change as a consequence
of this change.
A substantial change to the script's runtime environment is that many
globals that previously existed are now only exposed whenever needed.
This means for example that Simple Test harness functionality (waitFor,
ok, isnot, is, &c.) is only available when using a sandbox augmented
with a Simple Test harness adapter.
Conversely, this patch does not expose marionetteScriptFinished as a
callback to asynchronous scripts for sandboxes which sandboxName parameter
is undefined, because this is what determines if the script should be
evaluated under WebDriver conformance constraints. In all other cases
where sandboxName _is_ defined, the traditional marionetteScriptFinished
et al. runtime environment is preserved.
MozReview-Commit-ID: 8FZ6rNVImuC
--HG--
extra : rebase_source : 38cc7b1e374fd42afb213133fd1a5e11bf8bdd95
Generally, Error prototypes that are not based on WebDriverError must
be wrapped so that they can be serialised across the AsyncMessageChannel.
MozReview-Commit-ID: EtkpEOBhrST
--HG--
extra : histedit_source : c35a686b6b9cea4ae50d0d63223f4cdde6f6e4a2
extra : rebase_source : 4aad87845982cc81fec375ae9f63223a58003aec
extra : commitid : 825ScXhXQSy
extra : source : 1f5e37f8e44641e5434d8393f307f2ea4e80cdc6
extra : intermediate-source : dc6460e0f336c151be27bd124935b52361ea9557
Due to a previous programming error, error.isError only recognised
the base Error prototype. It must also test for the other built-in
prototypes, such as TypeError et al.
MozReview-Commit-ID: HLkiOAg0Jl1
--HG--
extra : histedit_source : 77fd0e6b6471b18528c27954e6348f93fc520d64
extra : rebase_source : 0e6d2085c37f2a2646c560b10e0c35eead6fcd3a
extra : commitid : F50Xhg2Q86e
extra : source : aec0a01666851a1e03dcb139e1766bae0c1b0fd7
extra : intermediate-source : 36526a2e8b0071b9f51cc30d5b6e0b5c345ec437
Generally, Error prototypes that are not based on WebDriverError must
be wrapped so that they can be serialised across the AsyncMessageChannel.
MozReview-Commit-ID: EtkpEOBhrST
--HG--
extra : commitid : 825ScXhXQSy
extra : rebase_source : 1d2b7022e311ced9a07830f1017449fbb6220454
extra : source : 1f5e37f8e44641e5434d8393f307f2ea4e80cdc6
extra : histedit_source : c35a686b6b9cea4ae50d0d63223f4cdde6f6e4a2
Due to a previous programming error, error.isError only recognised
the base Error prototype. It must also test for the other built-in
prototypes, such as TypeError et al.
MozReview-Commit-ID: HLkiOAg0Jl1
--HG--
extra : commitid : F50Xhg2Q86e
extra : rebase_source : e7a81b7c07a59209c689b9a53895c17377e39692
extra : source : aec0a01666851a1e03dcb139e1766bae0c1b0fd7
extra : histedit_source : 77fd0e6b6471b18528c27954e6348f93fc520d64
Generally, Error prototypes that are not based on WebDriverError must
be wrapped so that they can be serialised across the AsyncMessageChannel.
--HG--
extra : commitid : 825ScXhXQSy
extra : rebase_source : c525b539b5139d479ea562614c26e46d3fb01bb8
extra : histedit_source : c35a686b6b9cea4ae50d0d63223f4cdde6f6e4a2
Due to a previous programming error, error.isError only recognised
the base Error prototype. It must also test for the other built-in
prototypes, such as TypeError et al.
--HG--
extra : commitid : F50Xhg2Q86e
extra : rebase_source : 3f757bf9667763718d54fcb6912156bcdcd9e787
extra : histedit_source : 77fd0e6b6471b18528c27954e6348f93fc520d64
This fixes an instance of passing an Error prototype over the message
manager as a CPOW. We solve this by marshaling the error, which is
now done automatically by the new AsyncMessageChannel. It allows us to
create an (almost) transparent promise-based interface between chrome-
and content contexts.
The patch also makes AsyncMessageChannel reusable on both sides of the
message listener, but it's currently not used at its maximum potential
because of the way the listener is architected.
--HG--
extra : commitid : EQd5E4Digdv
extra : rebase_source : 8e0c36960759d25c73bbbc0f4f0bcb453c1028f4
extra : amend_source : 6bb6a76a8b30a5524639f8236291980b16402e6a
Previously fnName and line was tested as the entry requirement for
printing the filename to the trace information. Testing line here was
premature since it is meant to be an optional argument.
This patch rectifies this behaviour by testing for each of the optional
arguments sequentially. This means the file argument is required to print
the line, and the fnName argument is required to print any of those two.
--HG--
extra : rebase_source : 484be6c8e09c8d4c5e6ce25e12ffc522d8111963
Previously fnName and line was tested as the entry requirement for
printing the filename to the trace information. Testing line here was
premature since it is meant to be an optional argument.
This patch rectifies this behaviour by testing for each of the optional
arguments sequentially. This means the file argument is required to print
the line, and the fnName argument is required to print any of those two.
--HG--
extra : rebase_source : d6490c7a8c393fdad2a4d008db82bdf0f1010175
The current test of the `result' property does not always pass for all
types of XPCOM exceptions. A safer test is to do an instance check
against Components.interfaces.nsIException.
This fixes hangs such as the one described in bug 1202576.
r=dburns
--HG--
extra : rebase_source : 040d84c83ea8462c852d1bede96375d7133bf319
Message sequencing allows Marionette to provide an asynchronous,
parallel pipelining user-facing interface, limit chances of payload
race conditions, and remove stylistic inconsistencies in how commands
and responses are dispatched internally.
Clients that deliver a blocking WebDriver interface are still be expected
to not send further command requests before the response from the last
command has come back, but if they still happen to do so because of
programming error or otherwise, no harm will be done. This will guard
against bugs such as bug 1207125.
This patch formalises the command and response concepts, and applies
these concepts to emulator callbacks. Through the new message format,
Marionette is able to provide two-way parallel communication. In other
words, the server will be able to instruct the client to perform a
command in a non ad-hoc way.
runEmulatorCmd and runEmulatorShell are both turned into command
instructions originating from the server. This resolves a lot of
technical debt in the server code because they are no longer special-cased
to circumvent the dispatching technique used for all other commands;
commands may originate from either the client or the server providing
parallel pipelining enforced through message sequencing:
client server
| |
msgid=1 |----------->|
| command |
| |
msgid=2 |<-----------|
| command |
| |
msgid=2 |----------->|
| response |
| |
msgid=1 |<-----------|
| response |
| |
The protocol now consists of a "Command" message and the corresponding
"Response" message. A "Response" message must always be sent in reply
to a "Command" message.
This bumps the Marionette protocol level to 3.
r=dburns
r=jgriffin
--HG--
extra : commitid : 1kz4Oa2q3Un
Message sequencing allows Marionette to provide an asynchronous,
parallel pipelining user-facing interface, limit chances of payload
race conditions, and remove stylistic inconsistencies in how commands
and responses are dispatched internally.
Clients that deliver a blocking WebDriver interface are still be expected
to not send further command requests before the response from the last
command has come back, but if they still happen to do so because of
programming error or otherwise, no harm will be done. This will guard
against bugs such as bug 1207125.
This patch formalises the command and response concepts, and applies
these concepts to emulator callbacks. Through the new message format,
Marionette is able to provide two-way parallel communication. In other
words, the server will be able to instruct the client to perform a
command in a non ad-hoc way.
runEmulatorCmd and runEmulatorShell are both turned into command
instructions originating from the server. This resolves a lot of
technical debt in the server code because they are no longer special-cased
to circumvent the dispatching technique used for all other commands;
commands may originate from either the client or the server providing
parallel pipelining enforced through message sequencing:
client server
| |
msgid=1 |----------->|
| command |
| |
msgid=2 |<-----------|
| command |
| |
msgid=2 |----------->|
| response |
| |
msgid=1 |<-----------|
| response |
| |
The protocol now consists of a "Command" message and the corresponding
"Response" message. A "Response" message must always be sent in reply
to a "Command" message.
This bumps the Marionette protocol level to 3.
r=dburns
r=jgriffin
--HG--
extra : commitid : 2upWRuXyqPF
extra : rebase_source : f384801e209e4b49ef57055fd550c3c435ece4ef
Moves most of the cookie implementation to a new file,
testing/marionette/cookies.js. The new Cookies class encapsulates all
APIs for manipulating and querying cookies from content space.
It communicates with chrome space, where the cookie manager lives, through
a new SyncContentSender provided by testing/marionette/proxy.js. This new
interface provides synchronous and transparent communication from content
to chrome, not dissimilar from how the original listener proxy works.
r=dburns
--HG--
extra : commitid : 7jF7OFSx4Yk
extra : rebase_source : 8fc73fb59196f8076e85673d002c42e2ae458ad0
Andreas Tolfsen
Andreas Tolfsen
David Burns
Maja Frydrychowicz
Thomas Charles
Sebastian Hengst
Wes Kocher
Carsten "Tomcat" Book
Phil Ringnalda
Shu-yu Guo
Alexandre Poirot