In the case of two or more firefox instances started from the same binary but with different profiles, if any one of those does a software update, the updater app will happily do its thing thus causing massive problems for the other running instances. There really needs to be some sort of lock in the application directory or something similar to indicate that there are no firefox instances running. This isn't super high priority since it requires multiple profiles to be in use, but the same would happen for a shared install of firefox.

I've seen this on Linux too. The Windows installer has code to shut down other instances, which might be useful on that platform.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051027 Firefox/1.5 ID:2005102721 I see this (trunk): http://img386.imageshack.us/img386/8650/update0yu.png After closing both instances and restarting one, it updates everything before opening, and it says, it is successful.

(In reply to comment #2) > I see this (trunk): http://img386.imageshack.us/img386/8650/update0yu.png > After closing both instances and restarting one, it updates everything before > opening, and it says, it is successful. Does the update start again and again? Then it is bug 340535. (In reply to comment #1) > The Windows installer has code to shut down other instances, which might be > useful on that platform. I add Robert who is working on the NSIS installer implementation.

This is true of both multiple profiles and the new -app switch to run xulapps on firefox. If we are going to be suggesting people use the -app switch to run their applications then we should be fixing this.

This is, hmm, annoyingly bad. Robert, will bug 340535 help here?

IMO yes... bug 340535 will make it so an OS reboot will be required if files are in use during software update.

But what prevents the user to autostart with the second profile and having the same problem again when starting his normal profile with the already downloaded update? I think it could happen more often for applications started with -app. We will run in an endless loop and aren't able to run the update. Except the user will be notified which process has opened the files.

The app exe is replaced with helper.exe and a notification telling the user that the IS must be restarted is displayed if they try to open the app along with the option to restart now.

Update of Target Milestone needed?

I remove TM since beta 3 is already released. Setting a new TM should be done by the assignee or drivers.

On discussion with Rob and Beltzner, we're going to minus this for Fx3, as we are not 100% confident that the solution won't break edge cases. This isn't a regression from Fx3, so we're at least not making things worse, and we're going to try to get to it after we ship so there's a lot of time to find edgecases.

This is now fixed on trunk and 1.9.2 for Firefox 3.6 via bug 525390