"browser.firstrun.*" seems to have been unused since the end of XUL-based
Fennec, whereas the code referencing the "browser.snippets.*" prefs was removed
in bug 1482836.
Differential Revision: https://phabricator.services.mozilla.com/D20862
--HG--
extra : moz-landing-system : lando
But enable it in all tests because a lot of them rely on using it in the
style="" attribute for example, or in inline stylesheets, which will no longer
parse this (even in chrome documents), and we don't want to rewrite all the XUL
and XBL tests.
Differential Revision: https://phabricator.services.mozilla.com/D18027
--HG--
extra : moz-landing-system : lando
This adds the app.update.checkInstallTime pref with a value of false in all tests that have the app.update.disabledForTesting pref except for geckodriver which is covered by bug 1508283.
This patch introduces 2 new prefs:
- devtools.console.stdout.chrome: if true, console API writes on stdout when
used by chrome code
- devtools.console.stdout.content: console API write on stdout when used by
content code.
This commit creates an empty 'base' profile because I wanted to preserve the
ability to apply a pref to all test harnesses on try. Since xpcshell doesn't
share many prefs with the other harnesses, it can't use the common profile.
So adding a pref to 'common' will apply it everywhere except xpcshell. Adding
a pref to 'base' will apply it everywhere including xpcshell. These profiles
are starting to get a bit messy, but I'd like to punt re-organizing them to a
follow-up bug.
Depends on D9716
Differential Revision: https://phabricator.services.mozilla.com/D9717
--HG--
extra : moz-landing-system : lando
This commit creates an empty 'base' profile because I wanted to preserve the
ability to apply a pref to all test harnesses on try. Since xpcshell doesn't
share many prefs with the other harnesses, it can't use the common profile.
So adding a pref to 'common' will apply it everywhere except xpcshell. Adding
a pref to 'base' will apply it everywhere including xpcshell. These profiles
are starting to get a bit messy, but I'd like to punt re-organizing them to a
follow-up bug.
Depends on D9716
Differential Revision: https://phabricator.services.mozilla.com/D9717
--HG--
extra : moz-landing-system : lando
Various web authors have expressed desire to know in advance whether autoplay
will work.
They want this in order to avoid paying the price for downloading media that
won't play. Or they want to take other action such as showing a poster image
instead.
This is of particular interest to Firefox, as we're planning on showing a
prompt to ask the user whether they would like a site to play. If sites want to
determine whether they can autoplay but avoid the prompt showing, they won't be
able to just call play() in Firefox and see whether it works, as that would
likely show the prompt if the user doesn't already have a stored permission.
We've been working out a spec here:
https://github.com/whatwg/html/issues/3617#issuecomment-398613484
This implements what is the consensus to date there;
HTMLMediaElement.allowedToPlay, which returns true when a play() call would not
be blocked with NotAllowedError by autoplay blocking policies.
MozReview-Commit-ID: AkBu0G7uCJ0
--HG--
extra : rebase_source : 3f31db79aa1e570fdd9fc7062d0ddac7c96a8931
We're going to enable block autoplay of HTMLMediaElements by default in Nightly,
but lots of our tests assume they are allowed to playback media without requiring
user interaction. After we've enabled block autoplay that assumption won't be valid.
So configure the prefs that control block autoplay so that we allow media to
autoplay.
This means the existing tests we have don't need to be rewritten to work when
we enable block autoplay by default.
MozReview-Commit-ID: 50yydubQjkS
--HG--
extra : rebase_source : a19e6c5b60d3b89e754be786281ca3242baa3830
Favicons will cause a small bit of additional network traffic and work in the
content process for any loaded page that doesn't specify a favicon. This turns
off attempts to guess a favicon when one isn't specified in performance tests.
Differential Revision: https://phabricator.services.mozilla.com/D1936
--HG--
extra : moz-landing-system : lando
This removes prefs that are already shared between reftest and the 'common' profile from:
testing/profiles/reftest/user.js
And moves prefs that were set in the 'common' profile but not reftest to both:
testing/profiles/unittest/user.js
testing/profiles/perf/user.js
MozReview-Commit-ID: HLfVrd2eD0l
--HG--
extra : rebase_source : ff186d28fa9bb081133bec06ee6689d59e66d41e
This factors out the prefs that are common across raptor, talos and
mochitest/web-platform-tests. In order to do this a new "unittest" profile has
been created.
This means, to set a pref across everything that uses this system, edit:
testing/profiles/common/user.js
To set a pref across unittest frameworks (which excludes raptor and talos),
edit:
testing/profiles/unittest/user.js
Setting a pref for perf frameworks only remains the same. Extensions follow
the same rules (drop them in <profile>/extensions).
MozReview-Commit-ID: 6AHlYsN0Lb8
--HG--
extra : rebase_source : aad259f06af549f3bc707fed5b1caaacf25bc28f
The main purpose of this script is to gain a view into the state of prefs
between various profiles or suites. There are three commands:
- show: Display prefs for the given profile or suite
- diff: Display differences of prefs between two profiles or suites
- sort: Sort pref files alphabetically for the given suite (this takes comments into account)
This also sorts common/user.js.
MozReview-Commit-ID: Bzl7w7i3glm
--HG--
extra : rebase_source : a8e620d06e9a940fadc7c3c0727e5c81ac3e3dfa
This moves testing/profiles/prefs_general.js to
testing/profiles/common/user.js. It also adds an 'extensions' folder to the
common profile. Dropping extension files here will get them installed in all
test harnesses (useful for testing on try).
The idea is that all test harnesses will eventually use this 'common' profile.
We'll also create some new per harness profiles, e.g testing/profiles/mochitest
and testing/profiles/reftest. This way there will be a single location
developers can go to set preferences, both for a specific harness, and across
all harnesses.
MozReview-Commit-ID: 8sqBqLiypgU
--HG--
rename : testing/profiles/prefs_general.js => testing/profiles/common/user.js
extra : rebase_source : 72a4a4b691e93c77479c7e70647b0ca373862c51
This moves testing/profiles/prefs_general.js to
testing/profiles/common/user.js. It also adds an 'extensions' folder to the
common profile. Dropping extension files here will get them installed in all
test harnesses (useful for testing on try).
The idea is that all test harnesses will eventually use this 'common' profile.
We'll also create some new per harness profiles, e.g testing/profiles/mochitest
and testing/profiles/reftest. This way there will be a single location
developers can go to set preferences, both for a specific harness, and across
all harnesses.
MozReview-Commit-ID: 8sqBqLiypgU
--HG--
rename : testing/profiles/prefs_general.js => testing/profiles/common/user.js
extra : rebase_source : 7599913e547533f2f57b597ad0f238c6cd391c82