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
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
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
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
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
Victor Porof
Dave Townsend
Coroiu Cristina