Errors thrown are printed to console and there is no point in having a
custom catch to print it.
This also makes it possible to start Marionette programmatically without
worrying about disappearing errors.
MozReview-Commit-ID: GGhyCyYqJg
--HG--
extra : rebase_source : 0a55dc87a2e3a3dab5da59800e421562b9385c51
Port 666 is in the protected port range and can not normally be bound
to unless the process is running with sudo permissions.
We can instead bind to port 0, which will give us a system-defined port
in the epemeral range.
MozReview-Commit-ID: Ld6BDMhtbck
--HG--
extra : rebase_source : 1ccbefb4829ba7d493a576e8339bae9174441484
This is a follow-up to address a fallout caused by bug 1344748 whereby
deprecated preferences relevant to Marionette are no longer being
picked up. This is preventing trace logs from being emitted in CI.
The old logic related to falling back to a deprecated preference is
faulty in that it the preferred, new preference always exists through
the power of testing/marionette/prefs.js. This patch introduces a new
helper method getPref that first looks at whether the preferred pref
is set, and only falls back to the deprecated if it isn't set and the
deprecation preference exists.
MozReview-Commit-ID: 8DeawLAELyK
--HG--
extra : rebase_source : b26a992ad9bda2423cb9033edbc1cb0ddfe12cfc
The Marionette component ships in Firefox, but is not enabled by default.
We want to facilitate activating Marionette at runtime by flipping
the marionette.enabled preference, and showing the Marionette related
preferences in about:config helps discoverability.
It is also useful to rely on the preferences' default values so that
they do not have to be hardcoded in the component.
When Marionette is enabled by setting marionette.enabled to true, a set of
recommended automation preferences found in testing/marionette/server.js
are set if the user has not overriden/user-defined one of them and
marionette.prefs.recommended is true (default). When Marionette is
stopped, the altered preferences are reset.
MozReview-Commit-ID: 3HLnEI0TEBB
--HG--
extra : rebase_source : 6557962c8dbd91002bbf22690ef03cd4cbcbbe38
Files appended to JS_PREFERENCE_FILES are moved into the
objdir/dist/bin/defaults/pref directory, shared with default global
preferences from other parts of Gecko.
To ensure Marionette's preference file ends up in this directory with
a sensible name, we put it in testing/marionette/prefs/marionette.js so
that it ends up in the objdir as dist/bin/defaults/pref/marionette.js.
MozReview-Commit-ID: 9YJ7vysDjSJ
--HG--
rename : testing/marionette/prefs.js => testing/marionette/prefs/marionette.js
extra : rebase_source : 54e084700d1ae691a0395531156626f56190f0fe
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
Behavior per spec and Chrome is to just delete the selection. We
already do this for insertHTML.
MozReview-Commit-ID: AWZhH6lIwuO
--HG--
extra : rebase_source : 353c3b628eb6a609de121e25bb7a11e579d29400
Update the refresh command to make it synchronous, and let it return
once the target page has been loaded. This can be accomplished by using
the loadListener object in listener.js.
MozReview-Commit-ID: Lc8QoGFeQrY
--HG--
extra : rebase_source : 1fd914aec1c55fe91a0de773cfd7ff22b5d12167
This refactoring allows us to re-use the same load algorithm for
each command which could trigger a page load. It also takes remoteness
changes into account, and waits until the load has been done.
With this change we no longer check for readyState only, but observe
the necessary DOM events as fired for page unloads and loads. This will
help us to implement the page loading strategy later.
By observing the DOM events, I also expect a small increase of performance
for any kind of page load, given that we now return immediately and do not
have a delay of 100ms at maximum.
MozReview-Commit-ID: IVtO6KgJFES
--HG--
extra : rebase_source : 40f90e3b9d1bf0a2f9123271cd08513769616e41
To delay the page load for our slowly served example page when using the
back or forward commands, the page doesn't have to be put into the browser
cache.
MozReview-Commit-ID: 4xMjR3SakZn
--HG--
extra : rebase_source : 024b8e702d95689defcee7e12496ce531e72d651
The key dispatch functions now pass the raw key to event.js,
which determines the keyCode for the event.
Note the change in Normalized Key Value for Enter versus Return.
The browser throws an exception when the event key attribute is
set to "Return" and KEY_NON_PRINTABLE_KEY is set, which implies
that the key value isn't valid. Changing it to Enter fixes the
issue.
MozReview-Commit-ID: 831f4EcqI1P
--HG--
extra : rebase_source : 6045b6199c72bcc7a971907d6e1513687d8ed3f9
Using non-remote pages causes framescripts to be reloaded. We should try
to avoid using those pages as much as possible, and test remoteness
switches in particular tests only. This is to reduce possible hangs.
MozReview-Commit-ID: ICPPkU07KQK
--HG--
extra : rebase_source : 7fdf1f2815790c70f4961cb004a3c066d9a2471e
If getting a test from the queue failed, we would loop forever rather
than trying the next queue.
MozReview-Commit-ID: K5YxCZPtx4l
--HG--
extra : rebase_source : f30618d0b26b740ba9748b912507fd03558f6d47
(For "Integrate and fully support OSX Signing in taskcluster")
Written as a mozharness script rather than using bare ./mach command because we need to download the upstream artifact
and because we need to download artifacts from tooltool to do the packing back into a .dmg. Future ideal would be to get
rid of the mozharness script and use JUST ./mach.
This is using the ./mach repackage code being created in Bug 1347576. Taking a signed tarball from a dmg supported with
Bug 1346015, and the taskgraph work to schedule this is in Bug 1318505.
MozReview-Commit-ID: rv9l285HKC
--HG--
extra : rebase_source : 054219511419b8bf44b1f57a8d834a12c13710e3
extra : intermediate-source : a52bc37e08efbf4d6c68cc0f4e2d4b76f79b192a
extra : source : 6ad7468a590f5a2779ffdc3713c1f6f74ce23731
There is no need to close this dialog given that a restart happens anyway.
But doing that as right now, and trying to invoke execute_script() on it,
will end up with a unlocatable window.
MozReview-Commit-ID: 53yBLYsWX4o
--HG--
extra : rebase_source : 21b02231c845cf994c7c75d10bd91e0911114998