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 : 56e99bb5d075b54dedc2a957e0f46a209a1e48a8
Code written by Manotej Meka <manotejmeka@gmail.com> and Ian Ferguson <fergu272@msu.edu>
This is the initial landing of the search feature, and is preffed off behind
browser.preferences.search.
MozReview-Commit-ID: 7iaeRsIIV3Y
--HG--
extra : rebase_source : 4444caea3622bcd2ff4ca49d23fa8b609e724146
FontBuilder adjusted font settings if reading font isn't available in the system. Now, we support empty string value of "font.name.*" which means default font in the system. If it's empty string, gfx checks default font from "font.name-list.*" at runtime. Therefore, resetting "font.name.*" to empty string is the best approach if specified font becomes not available (e.g., uninstalled from the system).
Therefore, this patch replaces the code in FontBuilder.readFontSelection() with just returning empty string.
MozReview-Commit-ID: HgR88Qw8Xwe
--HG--
extra : rebase_source : 3878bf6a1c98ef7ba27c2cbdaaa9307061820f85
CLOSED TREE
Backed out changeset 941e0f9ff9a7 (bug 1351074)
Backed out changeset 4fdf3b87a70b (bug 1351074)
Backed out changeset 586428f69838 (bug 1351074)
TESTING_JS_MODULES uses testing-common, not gre. So we should replace gre with testing-common for mochitest.
MozReview-Commit-ID: BqsS2D3IGR6
--HG--
extra : rebase_source : 2143fcdf33c428c82c6b2e00b542649b958aeccc
This patch also changes the 'headerURL' and 'theme_frame' properties to be of type
ExtensionURL, instead of strings. This improves validation robustness.
Alignment and tiling properties for the additional background images can be
specified in the newly introduced 'properties' section of the manifest.
MozReview-Commit-ID: BzvS3eHmDCY
--HG--
extra : rebase_source : 03560c0441bd2a6643c20a3f1fff8b905eca59ad
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
PrivacyLevel checks currently allow to disable storing secure cookies and any
cookies belonging to an HTTPS host, or completely disable storing cookies. We
call PrivacyLevel.canSave() for every host found in the shistory of a given
window's tabs. We then call it again for every cookie when retrieving all
cookies stored for a given host.
The two different privacy checks exist because in the past an HTTP site could
send a secure cookie too. Since Firefox 52 this isn’t possible anymore, only
HTTPS sites can send secure cookies. So as soon as nsICookie.isSecure=true
we know the site was loaded over TLS.
That means there are the following scenarios:
[PRIVACY_LEVEL=NONE] (default)
We store all cookies.
[PRIVACY_LEVEL=FULL]
We store no cookies at all.
[PRIVACY_LEVEL=ENCRYPTED]
HTTP site sends cookie: Store.
HTTP site sends secure cookie: Can't happen since Fx52
HTTPS site sends cookie: Store. The site is HTTPS but we should store the
cookie anyway because the "Secure" directive is missing. That means the
site wants us to send it for HTTP requests too.
HTTPS site sends secure cookie: Don't store.
This allows us to simplify the code and remove the per-host PrivacyLevel
checks. Checking nsICookie.isSecure is enough to tell whether we want
to keep a cookie or not.