1553781 - RemoteService fake profile is not entirely cleaned up when using XRemote

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[Mike Hommey [:glandium]]

The fake profile that is currently created in /tmp/firefox (see bug 1553771) is not always cleaned up.
STR:

• Open firefox
• With firefox open, run firefox https://someurl.com

What happens is that the fake profile is removed during startup of the first Firefox, but the Xremote call creates a new one, and doesn't clean it up entirely.

The reason for that, in turn, is that nsRemoteService::UnlockStartup() is never called when using the Xremote client. In fact, it's not called in all sorts of cases where XRE_main may fail. It seems like it should be called from the nsRemoteService destructor if it wasn't called manually already.

Comment 1

[Stéphane Gourichon]

Indeed, it is cleaned up when firefox is run on an account that had no firefox running.

But when running a second instance, the same directory is recreated but not cleaned up and /tmp/firefox/.parentlock still exists, locking out other users into a 5-second wait on each /usr/bin/firefox invocation.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1553829 for details.

Confirmed here on Xubuntu 18.04.

Symptom: 5-second lag before a new window appear

Steps to reproduce:

• user A runs Firefox (keeps running, don't quit)
• user B runs Firefox (keeps running, don't quit)
• each time user B calls /usr/bin/firefox from command line, there is a 5 second wait time before expected new window appears and command line returns.

In practice, the users use a global key shortcut to open another Firefox window, which causes /usr/bin/firefox to be run.

Before v67: a /tmp/firefox_$USER was created and not removed, leaving /tmp/firefox_$USER/.parentlock, which was not a real problem.
Since v67: the dir is /tmp/firefox with restricted permission, hold by user A. When user B tries, strace reveals this:

symlink("127.0.1.1:19986", "/tmp/firefox/lock") = -1 EACCES (Permission denied)

repeatedly for 5 seconds, then window appears.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1553829 for details.

Comment 2

[Dave Townsend [:mossop]]

Attachment: Bug 1553781: When the remote service finds an instance to remote to it doesn't clean up the startup lock.

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.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/18ace6e65729
When the remote service finds an instance to remote to it doesn't clean up the startup lock. r=glandium

Comment 5

[Narcis Beleuzu [:NarcisB]]

https://hg.mozilla.org/mozilla-central/rev/18ace6e65729