The forthcoming window tracking refactoring introduces the new
abstractions ContentContext and ChromeContext that to a large extent
share the same interface. They make it possible to interact with
both types of browsing context in a uniform manner.
Marionette currently has a lot of convoluted if-conditions to
paper over the differences between ChromeWindow, <xul:browser>,
and browser.Context. Examples of this includes the assert.window
and assert.contentBrowser assertions: they essentially perform the
same job, but does not share the same API because the underlying
APIs they call are different.
In an effort to prepare Marionette for the window tracking refactoring,
this patch adds a bit of glue to combine them both into one assertion
called assert.open. This checks that the browsing context has not
been discarded.
MozReview-Commit-ID: K5e7Sr1mq0
Introduces a new assert.acyclic assertion helper function that uses
JSON.stringify to test if the input contains cyclic object references.
A JavaScriptError will be thrown if the object is not acyclic.
MozReview-Commit-ID: 3y8pnkPgf2k
--HG--
extra : rebase_source : 069ae9e1e6d3738c8712fe5c1838f6d3a91125e4
The WebDriver service in the remote protocol accepts sessionId and
session_id and we only need on. All known consumers are using sessionId,
and we can drop the session_id fallback.
MozReview-Commit-ID: 6fa5Lgkzwfu
The last commit discovered a bug that one assertion's error message was
not being propagated. This adds extensive tests for this, for all the
remaining assertions to ensure this does not regress in the future.
MozReview-Commit-ID: EK91mUPeweG
--HG--
extra : rebase_source : f429a4cdd420c8d078419754d3cb0c39ac418ef1
The err argument to assert.object is currently being dropped, which
means we loose the specialised and the custom error message.
This patch propagates the error message like we do for all other
assertions in this module.
MozReview-Commit-ID: GwuBSbqKfk1
--HG--
extra : rebase_source : 86c57aaaf60526eaf65345b9d5e38378920419e3
Due to the current caching of this.tab in browser.js the assertion
for the contentBrowser would fail. As such additionally assert that
the currently selected chrome window has not been closed yet.
Also assert.window should better check the 'closed' property instead
of handling a possible TypeError.
MozReview-Commit-ID: B79czg3dsux
--HG--
extra : rebase_source : 31bf31d2151e4b461574101ce7770d38fb92bd5c
When accessing a property of the current content browser from
the parent process, the current top-level browsing context has
to be valid.
MozReview-Commit-ID: BZHJTk1j5Nj
--HG--
extra : rebase_source : 7e44fc6e05d7fb1429fb3e36e897cf51b3d9142f
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
The assertion method is used to check for a valid window. But it can fail
itself when already accessing the ChromeWindow. To fix that we have to
catch a possible TypeError and let the method throw a NoSuchWindowError
instead.
MozReview-Commit-ID: 3Uaio4a3HtA
--HG--
extra : rebase_source : 5c672e441789e45b4972b0f8fde8471b4998394d
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
The implementation of the new library function `assert.in` is analogous
to Python's `unittest.TestCase.assertIn`.
MozReview-Commit-ID: 1pjS9ttPXgo
--HG--
extra : rebase_source : 3f4121226d65f127fdf0c990915483659f3a7f93
Calling `typeof` on arrays or null in JavaScript returns `"object"`,
and a safer check is to rely on `Object.prototype.toString`.
MozReview-Commit-ID: 5VxXf2ByoEx
--HG--
extra : rebase_source : 4d1fe95a75343964836e670d0ceffa6ce680e390
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
Andreas Tolfsen
Henrik Skupin
Andreas Tolfsen
Maja Frydrychowicz