Handle stale lockfiles in Muon browser profile

[garrettr]

Resolves brave/brave-browser#2503.

If the initial attempt to create the ProcessSingleton fails, it may be the case that there are stale lockfiles or an unresponsive process holding lockfiles for Muon's user data directory. This PR will retry acquiring the browser profile lock with ProcessSingleton::NotifyOtherProcessOrCreatte, which attempts to handle those edge cases.

Tested and confirmed to work on macOS; waiting on builds to confirm this approach also works on Windows and Linux.

Submitter Checklist:

• Submitted a ticket for my issue if one did not already exist.
• Used Github auto-closing keywords in the commit message.
• Added/updated tests for this change (for new code or code which already has tests).
• Verified that these changes build without errors on
  • Windows
  • macOS
  • Linux
• Verified that these changes pass automated tests (npm test brave_unit_tests && npm test brave_browser_tests) on
  • Windows
  • macOS
  • Linux
• Ran git rebase master (if needed).
• Ran git rebase -i to squash commits (if needed).
• Tagged reviewers and labelled the pull request as needed.
• Request a security/privacy review as needed.
• Add appropriate QA labels (QA/Yes or QA/No) to include the closed issue in milestone

Test Plan:

This PR only needs to be tested on macOS and Linux. I tried but was unable to come up with a reproducible test plan for Windows.

1. Start Muon
2. Verify that this creates several new files, Singleton{Cookie,Lock,Socket}, in Muon's user data directory, e.g. on macOS: ls -l ~/Library/Application\ Support/brave/Singleton*
3. Extract Muon's PID from SingletonLock, e.g. on macOS: readlink ~/Library/Application\ Support/brave/SingletonLock | awk -F- '{print $NF}'
4. Terminate the Muon process (with extreme prejudice), e.g. on macOS: kill -9 <muon PID>
5. Verify that the Singleton files remain in the user data directory. They should not be cleaned up automatically, as they would be if Muon had exited cleanly.
6. Launch Brave Core and try to import from Muon; allow keychain access if/when prompted.

Importing all data types from Muon should be successful. You should not see the "Close Brave (old)" dialog.

Reviewer Checklist:

• New files have MPL-2.0 license header.
• Request a security/privacy review as needed.
• Adequate test coverage exists to prevent regressions
• Verify test plan is specified in PR before merging to source

[garrettr]

Noticed a minor issue on Windows. In the regression test where I confirm that the original profile lock functionality is preserved, the following occurs:

1. Open Muon
2. Open Brave Browser
3. Attempt to import from "Brave (old)" in Brave Browser
4. The "Close Brave (old)" dialog appears.

Previously, the "Close Brave" dialog ended up in the foreground of all other windows on the desktop. After this change, the following occurs:

1. The "Close Brave" dialog is shown
2. Muon gets foregrounded, which may partially or totally obscure the "Close Brave" dialog, depending on Muon's window layout.

Why does Muon get foregrounded? Probably due to the "Notify" portion of NotifyOtherProcessOrCreate; I have not yet examined the Muon source to confirm.

[garrettr]

Confirmed that the issue of potentially obscuring the "Close Brave" dialog only affects Windows.

On macOS and Linux, Muon also gets foregrounded, but the "Close Brave" dialog still ends up on top of all the foregrounded Muon windows and is easily visible. This actually makes for a rather convenient user experience, in that it both explains that they need to quit Muon to continue the import and also shows Muon windows prominently, which makes it easy to find a Muon window and quit it from there.

Also confirmed that the Test Plan succeeds on macOS and Linux. I need to do some more testing on Windows, because the underlying mechanism, process_singleton_win.cc, differs significantly from the implementation use on macOS and Linux, process_singleton_posix.cc.

[garrettr]

After further testing, I cannot even reproduce the test plan on Windows on master. Even when I do what (as far as I know) is the closest equivalent to kill -9 on Windows, taskkill /f /t /im Brave.exe, the lockfiles are still cleaned up. After doing so, I find I can run the Brave-Core importer without any issues.

That suggests we only need to clean up stale lockfiles on macOS and Linux, so we should probably limit the change to those platforms because of the undesirable "Close Brave (old)" dialog covering behavior.

[garrettr]

I decided to split the difference and retain the original behavior on Windows, while adding the new stale lockfile handling on macOS and Linux, because:

1. I was able to create a reproducible test case on macOS and Linux, but was not able to do so on Windows.
2. The undesirable behavior described in Handle stale lockfiles in Muon browser profile #1105 (comment) only affects Windows.

Since I can't confirm that this PR improves things on Windows, but do now it creates a UI regression for the case where a user does a manual import while Muon is still open, I think it's best to keep things as they are on Windows and only implement this fix on macOS and Linux.

If more information comes to light, or someone is able to help me find a way to reproduce this issue on Windows, I'd be happy to take another look.

[garrettr]

ChromeProfileLock tests are failing, looking into it now.

[garrettr]

All tests are passing, this is ready for review.

[darkdh]

++

[kjozwiak]

@garrettr uplift request to 0.58.x approved after deliberating with @rebron 👍 Please add/remove all needed labels and ensure that the associated issues are moved into the correct milestone.

Before requesting uplift approval for beta, please make sure that the PR has already been merged into master/nightly and dev.

[garrettr]

• master: f5c1558
• 0.60.x: 897ba71
• 0.59.x: 6d4db4c
• 0.58.x: b2a53f7