Closed Bug 1553781 Opened 3 months ago Closed 3 months ago

RemoteService fake profile is not entirely cleaned up when using XRemote


(Toolkit :: Startup and Profile System, defect)

Not set



Tracking Status
firefox69 --- fixed


(Reporter: glandium, Assigned: mossop)




(1 file)

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

  • Open firefox
  • With firefox open, run firefox

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.

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 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("", "/tmp/firefox/lock") = -1 EACCES (Permission denied)

repeatedly for 5 seconds, then window appears.

See for details.

Assignee: nobody → dtownsend

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.
Duplicate of this bug: 1553829
Pushed by
When the remote service finds an instance to remote to it doesn't clean up the startup lock. r=glandium
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69
You need to log in before you can comment on or make changes to this bug.