The XRE_EXECUTABLE_FILE directory entry gives us the actual path that the binary
was launched with. On systems where the filesystem is case insensitive this
can be in any case, which ends up being a different install hash. This patch
ensures that we get the correct case for the install path before generating the
hash.
We have the problem of users who are already affected by this issue. This patch
also leaves the old hash available, if no default profile is found for the
correct hash then we also check for a profile for the old hash, if so we use it
for this hash going forwards. Testing this is kind of a pain, we have to add a
way to override the old hash that we will check against. I'm not totally happy with
how it is done here but not sure there is anything better.
This also adds a test that calling xpcshell with differing cases returns the
same install hash.
Differential Revision: https://phabricator.services.mozilla.com/D34774
--HG--
extra : source : 1a595782402c95aa1f7b26e892e38a500ebb9a77
extra : amend_source : 749b03b93cd4687a83cd696a5cbedc9f2ebc69fc
extra : histedit_source : 459eae02e0e953d5108fd6d7609d9e640eeb695e%2C9fdaaec17723a5e1e7d277d08cd41d16da99437f
The XRE_EXECUTABLE_FILE directory entry gives us the actual path that the binary
was launched with. On systems where the filesystem is case insensitive this
can be in any case, which ends up being a different install hash. This patch
ensures that we get the correct case for the install path before generating the
hash.
We have the problem of users who are already affected by this issue. This patch
also leaves the old hash available, if no default profile is found for the
correct hash then we also check for a profile for the old hash, if so we use it
for this hash going forwards. Testing this is kind of a pain, we have to add a
way to override the old hash that we will check against. I'm not totally happy with
how it is done here but not sure there is anything better.
This also adds a test that calling xpcshell with differing cases returns the
same install hash.
Differential Revision: https://phabricator.services.mozilla.com/D34774
--HG--
extra : rebase_source : 43277e55337f9198b0ec0e6ef8d03ece61c1c5a7
The XRE_EXECUTABLE_FILE directory entry gives us the actual path that the binary
was launched with. On systems where the filesystem is case insensitive this
can be in any case, which ends up being a different install hash. This patch
ensures that we get the correct case for the install path before generating the
hash.
We have the problem of users who are already affected by this issue. This patch
also leaves the old hash available, if no default profile is found for the
correct hash then we also check for a profile for the old hash, if so we use it
for this hash going forwards. Testing this is kind of a pain, we have to add a
way to override the old hash that we will check against. I'm not totally happy with
how it is done here but not sure there is anything better.
This also adds a test that calling xpcshell with differing cases returns the
same install hash.
Differential Revision: https://phabricator.services.mozilla.com/D34774
--HG--
extra : moz-landing-system : lando
In some situations dedicated profile support does not work well. This includes a
handful of linux distributions which always install different application
versions to different locations, some application sandboxing systems as well as
enterprise deployments. This environment variable provides a way to opt out of
dedicated profiles for these cases.
Differential Revision: https://phabricator.services.mozilla.com/D35249
--HG--
extra : moz-landing-system : lando
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
Kirk Steuber
Dorel Luca
Jorg K
Kris Maglione
Michael Kaply
mandy cheang
Tom Ritter
Gijs Kruitbosch
Jared Wein
Bogdan Tara
Tim Nguyen
Victor Porof
Dave Townsend
Csoregi Natalia
Alexander Surkov
Sylvestre Ledru
Andrew Swan
Brian Grinstead
Geoff Brown
Narcis Beleuzu
Jonas Allmann
Cosmin Sabou