The cookie service relies on the current document's
domain which is accessible from chrome space through
this.curBrowser.contentBrowser.contentURI.host.
As it is implemented currently, Marionette's cookie service jumps
between chrome- and content space more than necessary. This incurs
significant serialisation and IPC overhead, considering that the domain,
hostname, and current path information is readily available in chrome
space.
This patch removes all cookie-related functionality from
testing/marionette/listener.js, and implements a pure chrome-only
version of the service. It does, however, not try to fix conformance
issues with the WebDriver specification, of which there are many.
Some of the algorithms, especially to do with iteration over cookies,
implemented in cookie.iter, is also highly suboptimal. I have not
fundamentally changed any algorithms, and so my recommendation is to
address this later when addressing potential conformance bugs.
MozReview-Commit-ID: Fgs8ocbDJxb
--HG--
extra : rebase_source : 16470d5341459e40b1ceed12728451d517bbc490
This makes the `implicitWaitFor` utility from
testing/marionette/element.js generally available in Marionette.
It improves on the design of the old wait utility by providing
promise-like resolve and reject options to the evaluated function. These
can be used to indicate success or failure of waiting. If resolved, the
provided value is returned immediately. When rejected, the function is
evaluated over again until the timeout is reached or an error is thrown.
It is useful to indicate success and failure state because it saves the
calling code from guessing based on the return value. Guessing from
the return value can be problematic since there are certain types and
values in JavaScript that are ambigeous or misleading, such as the fact
that empty arrays are evaluated as a truthy value.
MozReview-Commit-ID: G8F99tdbiNb
--HG--
extra : rebase_source : 88647b1c7115f15649d5029391ff21567f9d527c
This makes the `implicitWaitFor` utility from
testing/marionette/element.js generally available in Marionette.
It improves on the design of the old wait utility by providing
promise-like resolve and reject options to the evaluated function. These
can be used to indicate success or failure of waiting. If resolved, the
provided value is returned immediately. When rejected, the function is
evaluated over again until the timeout is reached or an error is thrown.
It is useful to indicate success and failure state because it saves the
calling code from guessing based on the return value. Guessing from
the return value can be problematic since there are certain types and
values in JavaScript that are ambigeous or misleading, such as the fact
that empty arrays are evaluated as a truthy value.
MozReview-Commit-ID: G8F99tdbiNb
--HG--
extra : rebase_source : 1de77b97f0de71e0dc77fc47a6b1aab1ef88ea6f
This patch provides a (nearly) WebDriver conforming implementation
of capabilities in Marionette. The work remaining is pending further
clarification in the specification.
Capabilities are represented internally as a complex object provided
by `session.Capabilities`. Timeouts and proxy configuration are also
represented by the similar complex objects `session.Timeouts` and
`session.Proxy`, respectively.
The capabilities stored in `GeckoDriver#sessionCapabilities` are the
result of parsing user-provided desired- and required capabilities.
WebDriver now uses `firstMatch` and `alwaysMatch` primitives for
capabilities, but as this is considered a wider breaking change, the
move to these primitives will be done at a later stage. It’s prudent
to point out that the base techniques used with the new primitives
are similar to those implemented for `desiredCapabilities` and
`requiredCapabilities` in this patch, and that the work needed to adapt
them is considered trivial.
When capabilities are presented back to the user (the so called processed
capabilities), we call the `toJSON` implementation on the complex objects.
`session.Capabilities#toJSON` calls the internal function `marshal`
which ensures empty fields are dropped. `marshal` can be considered to
be a specialisation of the standard library `JSON.stringify`, which also
calls `toJSON` on entry values if they provide this function.
The changeset overall also provides a much deeper level of testing of
WebDriver capabilities.
MozReview-Commit-ID: 97xGt3cnMys
--HG--
extra : rebase_source : 98e0bde3fdfd811775d195b488cb1255f61e5772
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
Adds support for navigating to a fragment on the currenty visible document
without waiting for a DOM event that the document has been fully loaded.
This addresses https://github.com/mozilla/geckodriver/issues/150.
MozReview-Commit-ID: 7uiPT5cjGQE
--HG--
extra : rebase_source : f9152a6623a25c17e10dc3bc6552b8e635c21317
The xOffset and yOffset arguments to element.coordinates previously
checked loose falsiness. If a number <= 0 would be given as an argument,
they would not be used and it would return the centre of the element.
This change adds more checks, documentation, and tests.
MozReview-Commit-ID: KmsiVFipzWx
--HG--
extra : rebase_source : 96e6c8c127071356fec029f5eaa4254ae60930b3
Was originally there to work around a bug in the B2G on-device test
runner. Can now safely be removed after bug 1240723 was landed.
MozReview-Commit-ID: EZGfvYcP9ER
--HG--
extra : rebase_source : c2dc099b127b4bbd5988c386d15de72a3ab0bf40
Andreas Tolfsen
Andreas Tolfsen
Wes Kocher
Maja Frydrychowicz
aleth
Nigel Babu