Since bug 1518587 when a command line argument or environment variable requests
a profile refresh but no existing profile is selected we would just exit
thinking that there is some problem here. But it turns out that the installer
sometimes passes this argument when it doesn't know that the new install will
not use the existing profiles.
So instead we just ignore attempts to refresh when we create a new profile. To
do this we just have to remove the checks that bail out and continue to create
the new profile, nsAppRunner will see that a new profile has been created and
cancel the attempted refresh anyway:
https://searchfox.org/mozilla-central/rev/ddb81c7a43ffada1f6cb4200c4f625e50e44dcf3/toolkit/xre/nsAppRunner.cpp#2021
Differential Revision: https://phabricator.services.mozilla.com/D32891
--HG--
extra : moz-landing-system : lando
This fixes the issue in a few redundant ways:
* nsProfileLock is made to properly clean itself up when destroyed.
* nsRemoteService makes sure the unlock when destroyed.
* nsAppRunner unlocks when a remote client has been found.
Differential Revision: https://phabricator.services.mozilla.com/D32360
--HG--
extra : moz-landing-system : lando
commonDialog.xul and profileDowngrade.xul both may load early enough
during startup that they don't automatically get customElements.js.
The quick workaround here is just to load it explicitly in those documents.
Differential Revision: https://phabricator.services.mozilla.com/D29235
--HG--
extra : moz-landing-system : lando
On startup we record the size and modified time of the profile lists. If
changed we refuse to flush any new changes to disk. Also adds a getter to check
if they've changed so the UI can do something sensible.
All attempts to flush are now checked for success. In some cases in early
startup the failure mode isn't great, we just quit startup. The assumption
though is that it's extremely unlikely that the files will have changed on disk
in the time between when they are read and when profile selection occurs, likely
less than a second later.
The profile reset flow is changed to only delete the old profile and flush once
all the migration has completed, so if something fails the user gets back to
their old profile.
In testing I ended up having to fix bug 1522584 so background file deletions on
a background thread are safer.
I haven't implemented any UI tests right now since making modifications to the
profiles means modifying the actual user's profiles which I'm not keen to do.
See bug 1539868.
Differential Revision: https://phabricator.services.mozilla.com/D25278
--HG--
extra : rebase_source : b9fb01c5f2faaf7d534800b700bb02b8c88af023
extra : source : ad5ac4d5c8f7240809a205be2960924813f1e705
Disable gtests observed to fail on Android. Some of these are simple build
failures and failures due to file permissions or paths, while other failures
are more obscure.
Once Android gtests are running on mozilla-central, I will file follow-up
bugs inviting teams to investigate the failures and re-enable Android gtests
that are important to them.
Differential Revision: https://phabricator.services.mozilla.com/D26606
--HG--
extra : moz-landing-system : lando
The original name of the profile is irrelevant here since we aren't testing
a migration to profiles-per-install. On dev-edition DEDICATED_NAME is the same
as PROFILE_DEFAULT so we correctly make a new profile with a unique name.
Differential Revision: https://phabricator.services.mozilla.com/D26230
--HG--
extra : moz-landing-system : lando
This fixes two bugs. The first is that when the firefox profile migrator doesn't
know which profile to migrate it attempts to fall back to another profile. I
think this was intended to be the default but in bug 1322797 I ended up making
it the current profile, which is the profile we're restoring into now. I think
at this stage the profile directory doesn't even exist so things go wrong.
Changing to use the actual default works but....
When the profile migrator UI doesn't know what profile to migrate from it uses
the default profile. So if the profile you're actually trying to restore is not
the default we'll effectively throw its data into the archive and replace it
with data from the default profile. I'm inclined to say that if the migrator
does not know what profile to migrate from it should error at that point for
safety.
Why would the profile migrator not know what profile to migrate from? Because of
a long-standing text encoding problem. In C++ profile names are encoded in UTF8.
But we try to pass them to JS through an IDL parameter of type ACString. This
does no UTF8 decoding and so JS recieves an incorrect name if the name includes
non-ascii characters and so can't find the profile.
This patch fixes the IDL parameter to AUTF8String which does the decoding
correctly and so JS gets the name correctly.
We should probably think about whether just passing the nsIToolkitProfile object
to the migrator is a better choice here.
Differential Revision: https://phabricator.services.mozilla.com/D26250
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : rebase_source : d00edf1ceb200a73a60bb1a90afabcdf95b01acf
extra : intermediate-source : e1c9790cd3bee060da99ffe37026721e36bc46c3
extra : source : d4feb17faf013134f5eac8b5e19b714c56410973
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : moz-landing-system : lando
Removed all occurences of ondialogaccept.
Removed all occurences of ondialogcancel.
Replaced all removed attributes with event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D21227
--HG--
extra : moz-landing-system : lando
Originally we stored the new information about installation defaults in
installs.ini since older versions of Firefox would throw away any new data in
profiles.ini any time they made changes to the profiles. That does however mean
we have to load two files on startup.
This changes things so that we save all the data in profiles.ini as well as a
version tag and still save the install data into installs.ini. An older version
will throw away the install data and version tag from profiles.ini but leave
installs.ini alone. On startup if the version tag is gone from profiles.ini then
we reload the install data from installs.ini and put it back into profiles.ini.
At some point in the future where we don't care about supporting older versions
of Firefox we can just drop installs.ini entirely.
A lot of the changes here involve moving to loading profiles.ini into an
in-memory ini, keeping it up to date and flushing it to disk. This means that we
no longer throw away any information in the ini file that this version does not
understand allowing the possibility of adding new data to this file in the
future.
Differential Revision: https://phabricator.services.mozilla.com/D22576
--HG--
extra : moz-landing-system : lando
If configured to show the profile manager on startup we want to defer doing that
until after attempting to remote to an existing Firefox. So in the default
startup case (not first run, not when a profile is selected on the command line
and not when the profile manager is requested on the command line) let default
profile selection complete, check for an existing Firefox and only then check
that we're configure to show the profile manager on startup and show it then.
Differential Revision: https://phabricator.services.mozilla.com/D23410
--HG--
extra : moz-landing-system : lando
If the user selects a profile we will either remote the current arguments to it
or we'll restart into it. Either way we don't need to check if the profile is
locked at this point.
We also don't need to double check if the profile is missing since bug 1530615
landed.
Differential Revision: https://phabricator.services.mozilla.com/D22758
--HG--
extra : moz-landing-system : lando
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
Dave Townsend
Alexander Surkov
Sylvestre Ledru
Andrew Swan
Brian Grinstead
Geoff Brown
Csoregi Natalia
Narcis Beleuzu
Jonas Allmann
Cosmin Sabou
shindli
Ehsan Akhgari
Coroiu Cristina
Bogdan Tara
Magnus Melin
Varun Dey