On startup of a fresh dedicated profile show a welcome page and a modal dialog
to explain what has happened.
--HG--
extra : rebase_source : 1505cf27f900070debc1f9e1c71ec4bef3bc099d
extra : source : 05200c5388b4f7adc4414268727458515d7b9ed9
On startup of a fresh dedicated profile show a welcome page and a modal dialog
to explain what has happened.
--HG--
extra : rebase_source : a033baf831aa8b9fcfa95d1f921364632a837390
Add a scalar 'autoplay_default_blocked' which records a boolean value which indicates whether user is blocking autoplay by default.
Differential Revision: https://phabricator.services.mozilla.com/D17298
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
This patch implements -moz-gtk-csd-hide-titlebar-by-default media query
to check if the system titlebar should be disabled by default on Linux systems
(it's already disabled on Window/Mac).
It also removes explicit definition of browser.tabs.drawInTitlebar preference on Linux.
When browser.tabs.drawInTitlebar is missing the -moz-gtk-csd-hide-titlebar-by-default
is used to obtain the titlebar state. When browser.tabs.drawInTitlebar is set
in about:config or by Customize menu, the user peference is used instead of the default.
It also fixes a -moz-gtk-csd-available media query,
it was always true regardless the actual system setting.
Differential Revision: https://phabricator.services.mozilla.com/D16036
--HG--
extra : moz-landing-system : lando
Because older versions of Firefox auto-select a profile if there is only one in
the database when running dev-edition which uses its own profile we create a
default for normal channels to use. Currently the browser code is responsible
for doing this but it uses a bad heuristic for deciding when to do that. It's
much easier to do it from the profile manager when the dev-edition profile is
created.
Differential Revision: https://phabricator.services.mozilla.com/D16117
--HG--
extra : moz-landing-system : lando
If we QI nsIPropertyBag on an XPCWrappedNative wrapping an XPCWrappedJS, calling
the getProperty method might incorrectly end up calling .getProperty on the
XPCWrappedJS itself, because it also implements nsIPropertyBag.
This became a problem with same-compartment chrome globals because if we no longer
cross a compartment boundary, we don't create a new WrappedNative and can now end up
seeing the nsIPropertyBag if it got queried before nsIWritablePropertyBag.
Depends on D15076
Differential Revision: https://phabricator.services.mozilla.com/D15077
--HG--
extra : moz-landing-system : lando
The strict category should block third-party tracking cookies instead of all third-party cookies. This changes the requirements to match that category, so existing strict users will be moved to custom.
Differential Revision: https://phabricator.services.mozilla.com/D13325
--HG--
extra : moz-landing-system : lando
The strict category should block third-party tracking cookies instead of all third-party cookies. This changes the requirements to match that category, so existing strict users will be moved to custom.
Differential Revision: https://phabricator.services.mozilla.com/D13325
--HG--
extra : moz-landing-system : lando
We no longer set up a listener on a per-window basis for category preference changes.
Differential Revision: https://phabricator.services.mozilla.com/D12667
--HG--
extra : moz-landing-system : lando
nsIBrowserSearchService::currentEngine and nsIBrowserSearchService::defaultEngine are the same thing.
The use of defaultEngine makes more sense and thus we are phasing out the use of currentEngine and replace it with defaultEngine.
Differential Revision: https://phabricator.services.mozilla.com/D7972
--HG--
extra : moz-landing-system : lando
