This intermittent was likely occurring because we set the expiry timeout
for temporary permissions to a really low value in the previous test.
The failing test was only failing on slow machines, leading me to believe
that the time between setting and checking was larger than the 500ms timeout
defined in the previous test. Thus, the permission was reset on checking it.
The expiry pref was set using pushPrefEnv, which restores prefs only after
the entire test was run. To just eradicate this category of problems in
the future I moved the test that manipulates the expiry into its own file.
MozReview-Commit-ID: 3mc5xHY4XLn
--HG--
extra : rebase_source : 40f78258a975da9dca9a47beddcaaeea83649de3
This patch fixes a regression that we hit on Fennec when we handed over control
over language negotiation to LocaleService in bug 1347306.
The problem is that we currently do not have good Android bindings for
OSPreferences::GetSystemLocale and in result we could not negotiate
languages between user-selected OS locales and available locales.
The temporary solution implemented here binds android OS preferences to
`intl.locale.os` pref which is set on Locale:OS event in browser.js.
In LocaleService we add a listener on the pref to renegotiate languages
when OS locale changes.
MozReview-Commit-ID: KTqjYSzLNNO
--HG--
extra : rebase_source : 61b692e81ce67cdb15a7962e41ebe78164dbe1aa
For testing purposes it will be useful to be able to trigger crashes in Rust
code. Being able to trigger a panic seems like a good place to start. This
will make it easier to validate improvements in crash reporting.
MozReview-Commit-ID: Bh5rBieLLWW
--HG--
rename : toolkit/crashreporter/test/unit/test_crash_moz_crash.js => toolkit/crashreporter/test/unit/test_crash_rust_panic.js
extra : rebase_source : ba9f626ca2d2852f966e93401b8f8f7543615310
extra : source : 8c9117de1e7f40af42b7cbce25bc3780c032fe45
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
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 : d75ff2eff3941c2cb074d4f3983a70ebd66b8043
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 : 8be91ed46c443dd120cbc4b42c729cf3ae250b5f
The recommended Marionette preferences for use in automation are not so
useful when testing the browser itself. Many of the tests for Firefox
have highly specific requirements, and setting the recommended Marionette
preferences could for these mean a deterioration of test coverage.
The majority of test harnesses utilising Marionette use it to install
unsigned add-ons at runtime, and these preferences are not relevant in
this context.
To avoid an unfortunate and unintended regression in test coverage,
we skip using the recommended Marionette preferences when we test the
browser itself.
MozReview-Commit-ID: 4DeHZfQEX7d
--HG--
extra : rebase_source : bf31d336df7c4c28c04454338a912632087aa3ff
