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
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
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
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
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
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
When creating the profile for the first time, we're trying to copy files
that just don't exist, so we just skip that. No code in mozilla-central
or comm-central was using the optional argument to pass a custom default
profile either, so that goes away as well.
Dave Townsend
Csoregi Natalia
Dorel Luca
Coroiu Cristina
Mike Hommey
Panos Astithas
Hector Zhao
Geoff Lankow
Olli Pettay
Gervase Markham
Mitchell Field