If Firefox was using the default profile before restarting to upgrade to a build
supporting dedicated profiles then we should check if we can make the selected
profile the default for this build and if not create the user a new profile.
Differential Revision: https://phabricator.services.mozilla.com/D20415
--HG--
extra : moz-landing-system : lando
Remove all occurences of the above mentioned attributes and replace them by event handlers.
Minor changes to consuming functions to preserve functionality.
Differential Revision: https://phabricator.services.mozilla.com/D20368
--HG--
extra : moz-landing-system : lando
We cast the nsIToolkitProfileService to nsToolkitProfileService in a bunch of
places, might as well just hold that instead.
Differential Revision: https://phabricator.services.mozilla.com/D19414
--HG--
extra : moz-landing-system : lando
We cast the nsIToolkitProfileService to nsToolkitProfileService in a bunch of
places, might as well just hold that instead.
Differential Revision: https://phabricator.services.mozilla.com/D19414
--HG--
extra : moz-landing-system : lando
Using an old default profile that is empty (like from bug 1518591) causes us to
also show the user a welcome page when that isn't necessary.
Instead leave old empty profiles alone (older versions will use them as the
default), create a new profile but don't set the flag to say that the old
default was skipped.
Differential Revision: https://phabricator.services.mozilla.com/D19243
--HG--
extra : moz-landing-system : lando
Replacing existing getParentProcessScalars with a generic implementation of getProcessScalars
Differential Revision: https://phabricator.services.mozilla.com/D18861
--HG--
extra : moz-landing-system : lando
Previously we attempted to do this when XPCOM wasn't available so it always
failed to get the shell service. Instead set a flag telling us to do it later
when we choose the old default profile.
Also includes a block of code to attempt to fix the issue for existing nightly
users, this can be removed before betas.
Differential Revision: https://phabricator.services.mozilla.com/D18596
--HG--
extra : moz-landing-system : lando
This test verifies that taking the old-style default profile works. But on
dev-edition the old-style default is defined by the name not the default flag.
So make the test profile have both the default flag and the right name.
Differential Revision: https://phabricator.services.mozilla.com/D18744
--HG--
extra : moz-landing-system : lando
Use the information in compatibility.ini to detect that the current running
application is an older version than previously ran with the profile and in
that case open a UI allowing the user to launch the profile manager, launch
the previous instance of the application or quit.
Also includes the patch from bug 1523725.
--HG--
rename : browser/themes/shared/information.svg => toolkit/themes/shared/profile/information.svg
extra : rebase_source : 3bf8b329eb5ea9e71fe2f0ed34a7e44dfdc434fd
extra : intermediate-source : 21a801ca5f6d435509f93e1dee187cb6ca868c8f
extra : source : c9d89812bc226ca593119bf440cb4f5e50ac2ace
Set a telemetry scalar depending on the path taken during profile selection at
startup.
Differential Revision: https://phabricator.services.mozilla.com/D17696
--HG--
extra : rebase_source : bb4056c1c234f3aa61aedc8fddc87193f7aa45a9
extra : source : ebcd8225434ae82b837d632b5ef44bcc9dd5c5b0
Uses a different profile depending on the install directory of the application.
installs.ini is used to map a hash of the install directory to a profile
directory.
If no profile is marked as default for the current install we use a heuristic
explained in the code to decide whether to use the profile that would have
been used before this feature.
The feature is disabled in snap builds where the install directory changes for
every version of the app, but multiple instances cannot share profiles anyway.
A boolean flag is used to turn on the feature because in a later patch we need
to be able to turn off the behaviour at runtime.
Includes code folded in from bug 1518634, bug 1522751, bug 1518632 and bug 1523024.
--HG--
extra : rebase_source : 0250c70e992fd8369e52ccee3755cf116a894791
extra : intermediate-source : e69cac07b209ad4ef4229815ffd8138ed64c348e
extra : source : e406bf0bcd665bd0e54ddb13d9ae880004badef1
The current properties selectedProfile and defaultProfile are somewhat confusing
selectedProfile actually returns the default profile for the build and
defaultProfile returns the default profile for non-dev-edition builds. This
confusion leads to callers doing the wrong thing in some places.
What most code actually cares about is being able to set/get the default profile
for this build and getting the current profile in use. So this patch replaces
the previous properties with currentProfile and defaultProfile which do what
makes more sense.
This patch also switches from using the preprocessor to change behaviour for
dev-edition builds to using a boolean flag since some code was incorrectly
ignoring the setting to make dev-edition use the same profile as normal builds.
In order to make currentProfile correct when resetting a profile I had to move
CreateResetProfile into nsToolkitProfileService.
Differential Revision: https://phabricator.services.mozilla.com/D16118
--HG--
extra : rebase_source : cefe252618cd3a1b0e0cd5a71b056dd2b557f1a3
extra : intermediate-source : 35af79575f54f75d22e213fdac7ddd704b40807a
extra : source : 732d1ce192408d4f595f2fce16f45c7354ce3097
Use the information in compatibility.ini to detect that the current running
application is an older version than previously ran with the profile and in
that case open a UI allowing the user to launch the profile manager, launch
the previous instance of the application or quit.
Also includes the patch from bug 1523725.
--HG--
rename : browser/themes/shared/information.svg => toolkit/themes/shared/profile/information.svg
extra : rebase_source : f81be6c98b8248ca9a09c1e3d70cff2f925ad77f
extra : intermediate-source : 198a6d5b96d4127b6d21485a3b1b0ab2d3bc2f72
extra : source : c9d89812bc226ca593119bf440cb4f5e50ac2ace
Set a telemetry scalar depending on the path taken during profile selection at
startup.
Differential Revision: https://phabricator.services.mozilla.com/D17696
--HG--
extra : rebase_source : 6c797b4a8122db69e61d0d954dcfd726d3d1970e
Uses a different profile depending on the install directory of the application.
installs.ini is used to map a hash of the install directory to a profile
directory.
If no profile is marked as default for the current install we use a heuristic
explained in the code to decide whether to use the profile that would have
been used before this feature.
The feature is disabled in snap builds where the install directory changes for
every version of the app, but multiple instances cannot share profiles anyway.
A boolean flag is used to turn on the feature because in a later patch we need
to be able to turn off the behaviour at runtime.
Includes code folded in from bug 1518634, bug 1522751, bug 1518632 and bug 1523024.
--HG--
extra : rebase_source : b4608f6e8800af4f154daf0e0262f521c8ebd9fd
extra : intermediate-source : ba34b021c8e995ec7fc7c7fbb3dcc5dcf268278c
extra : source : e406bf0bcd665bd0e54ddb13d9ae880004badef1
The current properties selectedProfile and defaultProfile are somewhat confusing
selectedProfile actually returns the default profile for the build and
defaultProfile returns the default profile for non-dev-edition builds. This
confusion leads to callers doing the wrong thing in some places.
What most code actually cares about is being able to set/get the default profile
for this build and getting the current profile in use. So this patch replaces
the previous properties with currentProfile and defaultProfile which do what
makes more sense.
This patch also switches from using the preprocessor to change behaviour for
dev-edition builds to using a boolean flag since some code was incorrectly
ignoring the setting to make dev-edition use the same profile as normal builds.
In order to make currentProfile correct when resetting a profile I had to move
CreateResetProfile into nsToolkitProfileService.
Differential Revision: https://phabricator.services.mozilla.com/D16118
--HG--
extra : rebase_source : 24feb46363b5e43f35b51614d9dc6ae20ae49b65
extra : amend_source : 3c2051b98f19dc3288c59b0028db7d33c6953be3
extra : intermediate-source : 8404cc6140177a40c7086ddd4bf5d84735681048
extra : source : 732d1ce192408d4f595f2fce16f45c7354ce3097
***
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
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
Currently nsAppRunner is responsible for choosing or creating a profile to use
at startup. It then has to create a reset profile if necessary and lock the
selected profile directories. But these latter things are done in different
places of the selection code and done in different ways, sometimes we delay
while trying to get the lock, sometimes we don't.
This patch moves the profile selection part of the code to its own function so
that then we only have to have one place that does the profile reset and
locking logic.
It makes a lot of sense to have the selection code live in the profile service.
It can use information from the database load to help make the choices and it
also means that we can expose the profile selection code through xpcom allowing
it to be easily automatically tested. It will also be more important for future
patches for the dedicated profiles feature.
Differential Revision: https://phabricator.services.mozilla.com/D16116
--HG--
extra : moz-landing-system : lando
This allows JS callers to automatically get the correct types during
interation, without having to explicitly specify them.
Differential Revision: https://phabricator.services.mozilla.com/D3728
--HG--
extra : rebase_source : b708f382d8ea571d199c669bfed5b5a7ca9ffac4
extra : histedit_source : 7df6feb82088c8a5ca45dc28fe4d2b852c177fee
In order to allow JS callers to use nsISimpleEnumerator instances with the JS
iteration protocol, we'll need to additional methods to every instance. Since
we currently have a large number of unrelated implementations, it would be
best if they could share the same implementation for the JS portion of the
protocol.
This patch adds a stub nsSimpleEnumerator base class, and updates all existing
implementations to inherit from it. A follow-up will add a new base interface
to this class, and implement the additional functionality required for JS
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D3725
--HG--
extra : rebase_source : ad66d7b266856d5a750c772e4710679fab9434b1
extra : histedit_source : a83ebffbf2f0b191ba7de9007f73def6b9a955b8
These simple lists are converted to normal layout by setting a fixed height that isn't a multiple of the row height, which is already the case for most other lists in the user interface.
MozReview-Commit-ID: 1tV4MIoRp0d
--HG--
rename : toolkit/themes/windows/global/richlistbox.css => toolkit/themes/linux/global/richlistbox.css
extra : rebase_source : d6c53aa341bc5711f6ecf16485b5bd03d4f9caf2
extra : intermediate-source : 1355778929be17234ca3ced4f9930f05fb2cf20a
extra : source : 2e4527da76bba52492353aa5a40c128b09f389f1
This function is practically identical to the code used to salt the profile
directory except it was fixed to not return matching strings when called in the
same second by bug 867769.
Differential Revision: https://phabricator.services.mozilla.com/D1865
--HG--
extra : moz-landing-system : lando
This patch is an automatic replacement of s/NS_NOTREACHED/MOZ_ASSERT_UNREACHABLE/. Reindenting long lines and whitespace fixups follow in patch 6b.
MozReview-Commit-ID: 5UQVHElSpCr
--HG--
extra : rebase_source : 4c1b2fc32b269342f07639266b64941e2270e9c4
extra : source : 907543f6eae716f23a6de52b1ffb1c82908d158a
Currently stringbundle.js is loaded in response to the document-element-inserted message
in MainProcessSingleton. But since the profile manager loads before that script is run,
we don't register the Custom Element. This fixes that by explicitly including the script.
MozReview-Commit-ID: GqQk1VUv0Df
--HG--
extra : rebase_source : 1d958661865591b3e4260d566f83c5eb16bfa1b5
