NSIS installer is unable to close running instance of firefox

RESOLVED FIXED in Firefox 2 beta2

Status

()

RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: mossop, Assigned: rstrong)

Tracking

({fixed1.8.1})

Trunk
Firefox 2 beta2
x86
Windows XP
fixed1.8.1
Points:
---
Bug Flags:
blocking-firefox2 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
When running the installer while firefox is already running it prompts you to close firefox. If you click ok nothing happens and it prompts you again.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060530 Minefield/3.0a1 ID:2006053010 [cairo]
Confirmed: 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060529 Minefield/3.0a1,Firefox ID:2006053004
Hmmm... this is WFM on XP and Win2K. Some more details as to why this is happening for you would be appreciated
(Reporter)

Comment 3

13 years ago
Appears to work on branch, but not trunk. Tested with firefox running in safe mode and tried standard and custom installs.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060531 Minefield/3.0a1
Tried both installers of this build while another trunk build was already running on a different profile and they showed different behaviour.
The normal installer gave a prompt "Minefield must be closed to proceed with the installation. Click OK to exit Minefield automatically and to begin installation". I had not really a choice, so I clicked OK and firefox.exe disappeared from the task bar.
The NSIS installer acted differently. It ignored the running process, no prompt at all and after a few seconds I had two Minefield browsers running side by side.
(Reporter)

Comment 5

13 years ago
I did notice that running an NSIS branch installer didnt notice the running instance of minefield. But also the branch installer remembers where I install my branch version and the trunk version remembers where I install my trunk version so I guess its a case of looking at the place its installing to and warning if that particular firefox is running.
The XPInstall based installer has a fallback mechanism where it kills the process which I added then removed from the NSIS installer. I haven't had time to debug this and suspect it will be very difficult to find what caused this change in behavior.

The NSIS installer first tries to delete firefox.exe from the install location if it exists and if that fails prompts to close firefox. The XPInstall based installer looks for the Firefox message window's class and if that is present prompts to close.
I have a patch that fixes this for WinNT w/ psapi.sll and above (already includes psapi.dll). The psapi.dll can be redistributed and is 18 KB in size wiht about a 7 KB size penalty for the installer so we could get all of WinNT with this approach. For other versions of Windows we could just prompt to close. This patch only tries to close the instance of Firefox where we are installing to by getting the module filename.

I'm not sure what changed on trunk and the approach above is a bit overkill.

Comment 8

12 years ago
Robert, any word on the patch? 

I was just testing this on branch with an instance of Firefox 1.5 running and I wasn't even prompted to close it. Then when I chose to start Bon Echo now at the end of the installation a new window of 1.5 was opened.

I'm hoping your patch will fix this issue.
(In reply to comment #8)
> I was just testing this on branch with an instance of Firefox 1.5 running and I
> wasn't even prompted to close it. Then when I chose to start Bon Echo now at
> the end of the installation a new window of 1.5 was opened.
This bug is actually trunk only and what you are seeing is that we don't check for running instances when we offer to launch the first time. If you were to install into the same location that you have a running instance of Firefox when using a branch or 1.5 build it does prompt and close the running instance.
So, this has been a problem on the trunk and now it is a problem on the branch. Since we now have session restore this is not as simple as just killing the process due to that being treated the same as a crash (e.g. we will show the crash restore dialog). I have a patch I have been working on that needs tightening up and will try to have this finished Monday.

Requesting blocking and I think we need this for beta 1
Flags: blocking-firefox2?

Updated

12 years ago
Flags: blocking-firefox2? → blocking-firefox2+

Comment 11

12 years ago
Can we send the process a WM_QUIT message or some more forceful alternative?
We are already posting WM_QUIT to the AppShortNameMessageWindow and this recently stopped working on the 1.8.1 branch. ispiked will be trying to find the regression window. I am also working on an alternative approach though what I have will only work on NT and above.
Created attachment 228863 [details] [diff] [review]
use correct register in CloseApp and check if app is running before launching app
Assignee: nobody → robert.bugzilla
Status: NEW → ASSIGNED
Attachment #228863 - Flags: review?
Target Milestone: --- → Firefox 2 beta2
Comment on attachment 228863 [details] [diff] [review]
use correct register in CloseApp and check if app is running before launching app

Benjamin, there is still another issue on the trunk where posting WM_QUIT to the FirefoxMessageWindow (e.g. AppShortNameMessageWindow) is not working. That will need to be fixed outside of the installer code and I'll file a bug after I track down what caused the regression.
Attachment #228863 - Flags: review? → review?(benjamin)
Filed Bug 344309 for the trunk issue with the app not closing when posting WM_QUIT to the FirefoxMessageWindow.
Attachment #228863 - Flags: review?(benjamin) → review?(sspitzer)
Comment on attachment 228863 [details] [diff] [review]
use correct register in CloseApp and check if app is running before launching app

r=sspitzer

robert came over and explained this to me.
Attachment #228863 - Flags: review?(sspitzer) → review+
Checked in to trunk. For this to actually work on the trunk bug 344309 will need to be fixed as well.
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Attachment #228863 - Flags: approval1.8.1?

Updated

12 years ago
Attachment #228863 - Flags: approval1.8.1? → approval1.8.1+
Checked in to MOZILLA_1_8_BRANCH for Firefox 2.0
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.