Currently if there is a zombie firefox.exe process with a registered dde server the installer will not allow the user to install until the process has exited or more likely has been killed. We could work around this by only prompting the user to close the app once and then if the app is still in use just require a reboot to complete the installation.

Could the installer try to kill the process itself?

We used to do that and it turned into dataloss bugs. As a workaround for the installer in regards to Firefox not shutting down completely I am planning on warning once and then if the process is still present requiring an OS restart to finish the install by replacing the files that were in use.

Why would a kill from the installer cause dataloss bugs and a kill from OS shutdown not?

The OS typically does not kill the firefox.exe process. Apps have the ability to reply back to the shutdown windows message from the OS that they aren't ready to shutdown and there is also a timeout during shutdown after which Windows will kill an app that doesn't respond. What we are trying to workaround here is when Firefox is a zombie process where the only solution is to kill or require a reboot after completing the install. There is also the condition where a user doesn't realize Firefox is running and they have form data in a tab. Killing the process in this case causes dataloss and there have been bugs filed for this in the past which is why mconnor and I chose the current behavior where the installer never kills firefox.exe and instead prompts the user to close Firefox. With the number of users running Firefox on Windows this is a significant number of users though it is an extremely small percentage of the user base. The better solution would be to solve the zombie process problem though it doesn't appear that anyone has a firm understanding as to why that is happening plus our add-on / plugin / etc. story make it extremely unlikely that it would be solved entirely at present IMO though that may change in the future.

If I understand correctly, your answer to comment 2 is "Because maybe the existing process isn't a zombie, just a Firefox window the user forgot about". In that case, focusing Firefox would be more helpful than prompting the user to restart Windows.

That is by no means what we do now or what we would do in the future. We already prompt the user to close Firefox and we would continue to do so as I already stated. Once this bug is fixed the user would be prompted one time and if the process is still present the OS would need to be restarted to complete the install. There are no unique Window ID's besides the message window for Firefox so it is not possible to accurately just activate the Firefox window... so, if there are any other Mozilla processes running we would activate the wrong window. I do think it would be good to be able to accurately identify the Window for a specific Firefox process but the widget code would need to have this enhancement before the installer would be able to use it.

btw: I had a discussion about unique windows on Windows with both Darin and bsmedberg about 3 years ago... there aren't clean solutions to this but we could hack around it and be even more different than most apps on Windows.

This bug sounds like it would be closely tied to bug 490379.

It is similar in many ways except this is for the NSIS installer which is entirely different code

The zombie process is not only a problem during installation - its quite annoying all the time when you want to start Firefox and it is already running in the background! And non-tech-savvy users do not know how to kill a process.

Agreed. This bug is specifically about working around that issue for the installer since no one (including myself) has been able to understand / fix the cause of the zombie process which I believe is an already filed bug.

I'm going to take care of this in bug 367539

fyi: changed my mind about taking care of this in Bug 367539 since that bug is already complicated enough as is.

This is fixed in the stub installer so wontfixing.