Closed Bug 1529879 Opened 8 months ago Closed 6 months ago

The about:profiles page is not updated after a new profile is created

Categories

(Toolkit :: Startup and Profile System, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla68
Tracking Status
firefox65 --- wontfix
firefox66 --- wontfix
firefox67 + verified
firefox68 --- verified

People

(Reporter: Ovidiu, Assigned: mossop)

References

(Regressed 1 open bug)

Details

Attachments

(1 file)

Affected versions

  • Nightly 67.0a1

Affected platforms

  • Tested only on Mac OS X 10.14
    The other platforms are affected by a bug that doesn't support to open multiple installs at the same time. We will test the behaviour after the bug is fixed.

Steps to reproduce

  1. Open a Nightly
  2. Go to about:profiles - you have 2 profiles
  3. Open the second Nightly (leave the browser from step 1 open)
  4. Go to about:profiles - you have 3 profiles
  5. Go back to about:profiles page from step 2 and refresh it/close it and open another about:profiles tab

Expected result

  • The about:profiles page displays the same information as the one from step 4. You see 3 profiles listed.

Actual result

  • The about:profiles page is not updated with the information about the newly created profile even if the page is restarted or refreshed.
Blocks: 1474285
See Also: → 1530615

This is essentially a long-standing bug, probably going back to pre-Firefox-1.0 days. Firefox loads the profiles list on startup, if something else changes them after that Firefox won't know about it. This is going to become more visible though as we expect users to start using multiple installs and profiles more though.

Getting Firefox to reload the profiles database is a hard fix that will require a lot of thought. I think we can do a smaller fix to at least block us from overwriting changes that another Firefox may have made though.

Assignee: nobody → dtownsend

(In reply to Dave Townsend [:mossop] (he/him) from comment #1)

This is essentially a long-standing bug, probably going back to pre-Firefox-1.0 days.

Well, I guess arguably it wasn't really visible until about:profiles showed up!

The problem here is the obvious one. We load the data from profiles.ini on startup and never again. So if after startup profiles.ini is changed in any way we don't know about it. This has always been true. As you might expect if you try to modify profiles.ini from two different Firefoxes at the same time the changes from one of them will get thrown away when the second flushes. We've basically lived with this state for a while. Now however we anticipate that more users will be using multiple profiles so it's worth thinking of ways to at least reduce the risk of dataloss here.

The simple plan I've come up with is to be able to check whether profiles.ini has changed since this process loaded it. I'm proposing just a simple check, see if the last-modified time or size have changed. Then when we open about:profiles we show a page saying that you have to restart in order to make changes. When it attempts to flush we check again and show a message saying why they can't. That is the pretty straightforward case, a little inelegant but probably fine.

All the other cases are during startup. There is always a slim chance that during startup, between when we load the profiles and save any changes some other Firefox will make changes. The most likely of these is when showing the profile manager where the time between load and save is longer. These cases are a little more awkward but refusing to save changes would essentially block the user from getting into Firefox so I think we should just keep overwriting in this case. This should only be a problem very rarely.

Does this sound like a sane way to go? Any other ideas you can think of?

Flags: needinfo?(nfroyd)

(In reply to Dave Townsend [:mossop] (he/him) from comment #3)

The problem here is the obvious one. We load the data from profiles.ini on startup and never again. So if after startup profiles.ini is changed in any way we don't know about it. This has always been true. As you might expect if you try to modify profiles.ini from two different Firefoxes at the same time the changes from one of them will get thrown away when the second flushes. We've basically lived with this state for a while. Now however we anticipate that more users will be using multiple profiles so it's worth thinking of ways to at least reduce the risk of dataloss here.

We would still have this issue even if we converted profiles.ini to some other storage format, right? (rkv, sqlite, etc.)

The simple plan I've come up with is to be able to check whether profiles.ini has changed since this process loaded it. I'm proposing just a simple check, see if the last-modified time or size have changed. Then when we open about:profiles we show a page saying that you have to restart in order to make changes. When it attempts to flush we check again and show a message saying why they can't. That is the pretty straightforward case, a little inelegant but probably fine.

This seems fine.

All the other cases are during startup. There is always a slim chance that during startup, between when we load the profiles and save any changes some other Firefox will make changes. The most likely of these is when showing the profile manager where the time between load and save is longer. These cases are a little more awkward but refusing to save changes would essentially block the user from getting into Firefox so I think we should just keep overwriting in this case. This should only be a problem very rarely.

Just for clarification, the "blocking the user from getting into Firefox" is just if they want to do anything with a profile, right? They could conceivably exit the profile manager and things would be OK? (Well, maybe we write profiles.ini when we exit the profiler manager, and perhaps we should avoid doing that unless we have to?)

Does this sound like a sane way to go? Any other ideas you can think of?

Could we make the profile manager do something analogous to about:profiles here? Check for modification since the last load, and if the user does anything that requires profiles.ini modifications, then request that the user restart to ensure everything is up-to-date first? It's not the smoothest user experience (and there are probably a number of corner cases), but perhaps it's better than mysterious things happening to people's profiles?

Flags: needinfo?(nfroyd)

(In reply to Nathan Froyd [:froydnj] from comment #4)

(In reply to Dave Townsend [:mossop] (he/him) from comment #3)

The problem here is the obvious one. We load the data from profiles.ini on startup and never again. So if after startup profiles.ini is changed in any way we don't know about it. This has always been true. As you might expect if you try to modify profiles.ini from two different Firefoxes at the same time the changes from one of them will get thrown away when the second flushes. We've basically lived with this state for a while. Now however we anticipate that more users will be using multiple profiles so it's worth thinking of ways to at least reduce the risk of dataloss here.

We would still have this issue even if we converted profiles.ini to some other storage format, right? (rkv, sqlite, etc.)

Yes because we hold all the data in memory, manipulate it there and the flush the entire file. Using something that can be incrementally updated would help but even that would be significant work to do.

The simple plan I've come up with is to be able to check whether profiles.ini has changed since this process loaded it. I'm proposing just a simple check, see if the last-modified time or size have changed. Then when we open about:profiles we show a page saying that you have to restart in order to make changes. When it attempts to flush we check again and show a message saying why they can't. That is the pretty straightforward case, a little inelegant but probably fine.

This seems fine.

All the other cases are during startup. There is always a slim chance that during startup, between when we load the profiles and save any changes some other Firefox will make changes. The most likely of these is when showing the profile manager where the time between load and save is longer. These cases are a little more awkward but refusing to save changes would essentially block the user from getting into Firefox so I think we should just keep overwriting in this case. This should only be a problem very rarely.

Just for clarification, the "blocking the user from getting into Firefox" is just if they want to do anything with a profile, right? They could conceivably exit the profile manager and things would be OK? (Well, maybe we write profiles.ini when we exit the profiler manager, and perhaps we should avoid doing that unless we have to?)

Yes, that's right. And yes I need to stop always flushing after showing the profile manager.

Does this sound like a sane way to go? Any other ideas you can think of?

Could we make the profile manager do something analogous to about:profiles here? Check for modification since the last load, and if the user does anything that requires profiles.ini modifications, then request that the user restart to ensure everything is up-to-date first? It's not the smoothest user experience (and there are probably a number of corner cases), but perhaps it's better than mysterious things happening to people's profiles?

Yeah maybe that is a good idea. Thanks.

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.

Tracking for 67 as a potential uplift

Hardware: Unspecified → All
OS: Unspecified → All

Apparently re-requesting review in Phabricator doesn't work? Can you look over the last changes here, should be pretty straightforward.

Flags: needinfo?(nfroyd)
Flags: needinfo?(gijskruitbosch+bugs)

(In reply to Dave Townsend [:mossop] (he/him) from comment #8)

Apparently re-requesting review in Phabricator doesn't work? Can you look over the last changes here, should be pretty straightforward.

LGTM, thanks.

Flags: needinfo?(nfroyd)

Left feedback on phab.

Flags: needinfo?(gijskruitbosch+bugs)
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/77dbf6f2d6d4
Block changing the profile list when another process has changed it. r=froydnj,Gijs,flod

Backed out changeset 77dbf6f2d6d4 (bug 1529879) for Windows build bustages at Unified_cpp_toolkit_profile0.obj on a CLOSED TREE.

Backout link: https://hg.mozilla.org/integration/autoland/rev/f5273f8e51966ff5d45588bfcd1826a5642ba8b4

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception&selectedJob=241067954&revision=77dbf6f2d6d4f9825e9041946f4cb78c75f5a8dd

Log link: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=241067954&repo=autoland&lineNumber=25770

Log snippet:

00:05:21 INFO - z:/build/build/src/sccache2/sccache.exe z:/build/build/src/clang/bin/clang.exe --driver-mode=cl -m32 -FoUnified_cpp_toolkit_profile0.obj -c -Iz:/build/build/src/obj-firefox/dist/stl_wrappers -DNDEBUG=1 -DTRIMMED=1 -DSTATIC_EXPORTABLE_JS_API -DMOZ_HAS_MOZGLUE -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL -Iz:/build/build/src/toolkit/profile -Iz:/build/build/src/obj-firefox/toolkit/profile -Iz:/build/build/src/toolkit/xre -Iz:/build/build/src/obj-firefox/dist/include -Iz:/build/build/src/obj-firefox/dist/include/nspr -Iz:/build/build/src/obj-firefox/dist/include/nss -MD -FI z:/build/build/src/obj-firefox/mozilla-config.h -DMOZILLA_CLIENT -Qunused-arguments -guard:cf -Qunused-arguments -fcrash-diagnostics-dir=z:/build/public/build -TP -nologo -Zc:sizedDealloc- -D_HAS_EXCEPTIONS=0 -guard:cf -W3 -Gy -Zc:inline -arch:SSE2 -Gw -Wno-inline-new-delete -Wno-invalid-offsetof -Wno-microsoft-enum-value -Wno-microsoft-include -Wno-unknown-pragmas -Wno-ignored-pragmas -Wno-deprecated-declarations -Wno-invalid-noreturn -Wno-inconsistent-missing-override -Wno-implicit-exception-spec-mismatch -Wno-unused-local-typedef -Wno-ignored-attributes -Wno-used-but-marked-unused -D_SILENCE_TR1_NAMESPACE_DEPRECATION_WARNING -GR- -Z7 -Xclang -load -Xclang z:/build/build/src/obj-firefox/build/clang-plugin/clang-plugin.dll -Xclang -add-plugin -Xclang moz-check -O2 -Oy- -WX -Xclang -MP -Xclang -dependency-file -Xclang .deps/Unified_cpp_toolkit_profile0.obj.pp -Xclang -MT -Xclang Unified_cpp_toolkit_profile0.obj z:/build/build/src/obj-firefox/toolkit/profile/Unified_cpp_toolkit_profile0.cpp
00:05:21 INFO - In file included from z:/build/build/src/obj-firefox/toolkit/profile/Unified_cpp_toolkit_profile0.cpp:20:
00:05:21 INFO - z:/build/build/src/toolkit/profile/nsToolkitProfileService.cpp(397,7): error: field 'mInstallDBModifiedTime' will be initialized after field 'mUpdateChannel' [-Werror,-Wreorder]
00:05:21 INFO - mInstallDBModifiedTime(0),
00:05:21 INFO - ^
00:05:21 INFO - 1 error generated.
00:05:21 INFO - z:/build/build/src/config/rules.mk:805: recipe for target 'Unified_cpp_toolkit_profile0.obj' failed
00:05:21 INFO - mozmake.EXE[4]: *** [Unified_cpp_toolkit_profile0.obj] Error 1
00:05:21 INFO - mozmake.EXE[4]: Leaving directory 'z:/build/build/src/obj-firefox/toolkit/profile'
00:05:21 INFO - z:/build/build/src/config/recurse.mk:74: recipe for target 'toolkit/profile/target' failed
00:05:21 INFO - mozmake.EXE[3]: *** [toolkit/profile/target] Error 2
00:05:21 INFO - mozmake.EXE[3]: *** Waiting for unfinished jobs....
00:05:21 INFO - mozmake.EXE[4]: Entering directory 'z:/build/build/src/obj-firefox/gfx/thebes'
00:05:21 INFO - gfx/thebes/gfxASurface.obj

Flags: needinfo?(dtownsend)
Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/081a659775d3
Block changing the profile list when another process has changed it. r=froydnj,Gijs,flod
Blocks: 1522584

Backed out for xpcshell perma failures.

Push with failure: https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=success%2Ctestfailed%2Cbusted%2Cexception&searchStr=windows%2C10%2Cx64%2Cdebug%2Cxpcshell%2Ctests%2Ctest-windows10-64%2Fdebug-xpcshell-e10s%2Cx%28x%29&revision=081a659775d32b167cb0e74b7fb0e7ab1aee7a62&selectedJob=241213736

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=241213736&repo=autoland&lineNumber=10467

17:43:44 INFO - TEST-START | toolkit/profile/xpcshell/test_clean.js
17:43:47 WARNING - TEST-UNEXPECTED-FAIL | toolkit/profile/xpcshell/test_clean.js | xpcshell return code: 0
17:43:47 INFO - TEST-INFO took 2922ms
17:43:47 INFO - >>>>>>>
17:43:47 INFO - PID 8276 | Unable to load \untrusted-startup-test-dll.dll; LoadLibraryW failed: 126[8276, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, NS_ERROR_UNEXPECTED) failed with result 0x80004005: file z:/build/build/src/extensions/cookie/nsPermissionManager.cpp, line 1026
17:43:47 INFO - PID 8276 | Couldn't convert chrome URL: chrome://branding/locale/brand.properties
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: Failed to get directory to cache.: file z:/build/build/src/security/sandbox/win/src/sandboxbroker/sandboxBroker.cpp, line 82
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: Couldn't get the user appdata directory. Crash events may not be produced.: file z:/build/build/src/toolkit/crashreporter/nsExceptionHandler.cpp, line 2528
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file z:/build/build/src/extensions/cookie/nsPermissionManager.cpp, line 2906
17:43:47 INFO - (xpcshell/head.js) | test MAIN run_test pending (1)
17:43:47 INFO - (xpcshell/head.js) | test run_next_test 0 pending (2)
17:43:47 INFO - (xpcshell/head.js) | test MAIN run_test finished (2)
17:43:47 INFO - running event loop
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: Could not get the program name for a cubeb stream.: 'NS_SUCCEEDED(rv)', file z:/build/build/src/dom/media/CubebUtils.cpp, line 385
17:43:47 INFO - toolkit/profile/xpcshell/test_clean.js | Starting
17:43:47 INFO - (xpcshell/head.js) | test pending (2)
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - profiles.ini should not exist yet. - true == true
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - installs.ini should not exist yet. - true == true
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Paths should always be relative in these tests. - "1" == "1"
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have the right number of profiles. - 1 == 1
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have the right name. - "dedicated" == "dedicated"
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should not be marked as the old-style default. - true == true
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should be no defaults for installs yet. - 0 == 0
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Start with last profile should match. - true == true
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should be the same number of profiles. - 1 == 1
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have the same name. - "dedicated" == "dedicated"
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have the same path. - "c:\\users\\task_1555607223\\appdata\\local\\temp\\xpc-profile-tjvl6j\\data\\Profiles\\7gm65ikz.dedicated" == "c:\\users\\task_1555607223\\appdata\\local\\temp\\xpc-profile-tjvl6j\\data\\Profiles\\7gm65ikz.dedicated"
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have seen the right profile selected. - null == null
17:43:47 INFO - PID 8276 | Missing installs.ini
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Backup installs.ini should match installs in profiles.ini - {} deepEqual {}
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should be set to start with the last profile. - true == true
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should be set to not start with the last profile. - true == true
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Paths should always be relative in these tests. - "1" == "1"
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should only see an install section if the ini version was correct. - {} == true
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have the right number of profiles. - 1 == 1
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have the right name. - "dedicated" == "dedicated"
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should not be marked as the old-style default. - true == true
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should be only one known install. - 1 == 1
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have marked the new profile as the default for this install. - "Profiles/7gm65ikz.dedicated" == "Profiles/7gm65ikz.dedicated"
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Start with last profile should match. - false == false
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should be the same number of profiles. - 1 == 1
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have the same name. - "dedicated" == "dedicated"
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have the same path. - "c:\\users\\task_1555607223\\appdata\\local\\temp\\xpc-profile-tjvl6j\\data\\Profiles\\7gm65ikz.dedicated" == "c:\\users\\task_1555607223\\appdata\\local\\temp\\xpc-profile-tjvl6j\\data\\Profiles\\7gm65ikz.dedicated"
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Should have seen the right profile selected. - [object XPCWrappedNative_NoHelper] == [object XPCWrappedNative_NoHelper]
17:43:47 INFO - TEST-PASS | toolkit/profile/xpcshell/test_clean.js | - Backup installs.ini should match installs in profiles.ini - {"F3A75FA5C905A056":{"default":"Profiles/7gm65ikz.dedicated","locked":"1"}} deepEqual {"F3A75FA5C905A056":{"default":"Profiles/7gm65ikz.dedicated","locked":"1"}}
17:43:47 INFO - (xpcshell/head.js) | test run_next_test 0 finished (2)
17:43:47 INFO - Unexpected exception NS_ERROR_DATABASE_CHANGED: Component returned failure code: 0x805800ca (NS_ERROR_DATABASE_CHANGED) [nsIToolkitProfileService.flush]
17:43:47 INFO - @Z:/task_1555607223/build/tests/xpcshell/tests/toolkit/profile/xpcshell/test_clean.js:60:11
17:43:47 INFO - run_next_test/_run_next_test/<@Z:\task_1555607223\build\tests\xpcshell\head.js:1437:22
17:43:47 INFO - _run_next_test@Z:\task_1555607223\build\tests\xpcshell\head.js:1437:38
17:43:47 INFO - run@Z:\task_1555607223\build\tests\xpcshell\head.js:688:9
17:43:47 INFO - _do_main@Z:\task_1555607223\build\tests\xpcshell\head.js:227:6
17:43:47 INFO - _execute_test@Z:\task_1555607223\build\tests\xpcshell\head.js:529:5
17:43:47 INFO - @-e:1:1
17:43:47 INFO - exiting test
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: OOPDeinit() without successful OOPInit(): file z:/build/build/src/toolkit/crashreporter/nsExceptionHandler.cpp, line 3104
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file z:/build/build/src/xpcom/base/nsTraceRefcnt.cpp, line 194
17:43:47 INFO - PID 8276 | [8276, Main Thread] WARNING: XPCOM objects created/destroyed from static ctor/dtor: file z:/build/build/src/xpcom/base/nsTraceRefcnt.cpp, line 194
17:43:47 INFO - PID 8276 | nsStringStats
17:43:47 INFO - PID 8276 | => mAllocCount: 18776
17:43:47 INFO - PID 8276 | => mReallocCount: 0
17:43:47 INFO - PID 8276 | => mFreeCount: 18774 -- LEAKED 2 !!!
17:43:47 INFO - PID 8276 | => mShareCount: 36870
17:43:47 INFO - PID 8276 | => mAdoptCount: 16533
17:43:47 INFO - PID 8276 | => mAdoptFreeCount: 16533
17:43:47 INFO - PID 8276 | => Process ID: 8276, Thread ID: 16044
17:43:47 INFO - <<<<<<<

Backout: https://hg.mozilla.org/integration/autoland/rev/313aab6b8a05c0cfd63bc11e4c514ff39f92ad13

Pushed by dtownsend@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/f7a15eb24f3d
Block changing the profile list when another process has changed it. r=froydnj,Gijs,flod
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68
Depends on: 1545736
Regressions: 1545736

Comment on attachment 9054296 [details]
Bug 1529879: Block changing the profile list when another process has changed it.

Beta/Release Uplift Approval Request

  • User impact if declined: Firefox may show incorrect information in the profile managers if a second instance has made changes since the first was opened. Making changes in the first instance may overwrite changes made in the second. This has been an issue for all of Firefox's history however we are expecting more users to be running multiple instances at a time going forwards.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: See bug summary.
  • List of other uplifts needed: Bug 1545736
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): The code touches a number of areas of startup though in theory this should actually make us do more sensible things when attempts to write the profiles database fails for whatever reason.
  • String changes made/needed: A couple of new dialogs have been added with title and message strings.
Flags: needinfo?(dtownsend)
Attachment #9054296 - Flags: approval-mozilla-beta?
Flags: qe-verify+
QA Whiteboard: [qa-triaged]

The issue is verified fixed on the latest nightly Fx68.0a1 on Ubuntu 18.04, macOS 10.14 and Windows 10 x64. The user receives a message in the about:profiles page to restart the browser.

Waiting for the uplift to beta to mark the bug as verified.

Comment on attachment 9054296 [details]
Bug 1529879: Block changing the profile list when another process has changed it.

Verified by QA on nightly + automated tests. It's a big patch for late beta but dedicated profiles is also a prominent new feature for this release, uplift approved for 67 beta 14, thanks.

Attachment #9054296 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

The issue is verified fixed using Fx67.0b14 buildID: 20190423190209 (intermediary build) on Ubuntu 18.04, macOS 10.14 and Windows 10 x64. The user receives a message in the about:profiles page to restart the browser when another dedicated install creates a dedicated profile.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
Regressions: 1546931
You need to log in before you can comment on or make changes to this bug.