Open Bug 1068650 Opened 10 years ago Updated 2 years ago

Sometimes Firefox does not start when restarting it immediately after closing it

Categories

(Toolkit :: Startup and Profile System, defect)

x86_64
Windows 7
defect

Tracking

()

People

(Reporter: FlorinMezei, Unassigned)

Details

Reproducible with:
Latest Firefox 34 Aurora - BuildID: 20140917004003
Latest Firefox 35 Nightly - BuildID: 20140917030202

Environment: Windows 7 x64

Steps to reproduce:
1. Open Firefox with a clean profile and set it to start without asking to pick a profile on startup.
2. Open 25 or more tabs with different websites.
3. Close Firefox.
4. Reopen Firefox and restore session.
5. Quickly select all tabs so they start to load (alternately you may also choose the option to "Reload All Tabs" and wait a few seconds for content to start loading).
6. Close Firefox and immediately attempt to restart it.

Expected results: 
Firefox starts correctly OR the new "Firefox already running" dialog displays.

Actual results:
Sometimes a new Firefox process is created and appears in the Task Manager, but nothing visible happens. After the initial process is finally killed (automatically after several seconds), then you can manually start Firefox again. See http://www.screencast.com/t/L0pb2JceY3bP.

Notes:
- multiple new processes can be launched without displaying anything if you keep trying to start Firefox.
- the issue is a follow up from bug 286355 which introduced the new "Firefox already running" dialog with the option to Close Firefox if the task is still running.
- the issue is intermittent but was reproduced multiple times without much effort (the key is to have many tabs loading when closing Firefox, and to very quickly try to restart it at step 6).
The issue here is that there is a race between the initial process shutting down and the second process starting up. The second process thinks it can send a message to the first process to open a new window, but the first process has already passed the point of no return.

The delays seen are because of a timeout in SendMessage(WM_COPYDATA) -- the second process is hung trying communicate with the first process, but the first process isn't able to process the message anymore.

There is probably stuff that we can do to make this more reliable, but I would say that it is not directly a profile unlocker issue, so I'm removing this bug as a blocker of Windows profile unlocking.
No longer blocks: 286355
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.