Closed Bug 1091605 Opened 5 years ago Closed 5 years ago

The windows installer bypasses the profile selection logic when it tries to launch the installed app

Categories

(Firefox :: Installer, defect)

x86
Windows 7
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 36
Tracking Status
firefox35 --- fixed
firefox36 --- verified

People

(Reporter: past, Assigned: past)

References

Details

Attachments

(1 file)

Bug 1024110 changed the way profile selection works for aurora builds. However the windows installer does not appear to use that logic when it tries to launch the app after installation.

What ends up happening is that after I use stable Firefox to download the installer, run it and after it's done, click finish (with the "launch Firefox now" checkbox ticked), I see the "Firefox is already running" message, as it tries to use the default profile. Exiting the installer and manually running the newly installed app works fine though.
Rob, do you know how to fix this, or can you point me to the code that launches the app?
Flags: needinfo?(robert.strong.bugs)
I think I've found it, the LaunchApp function in installer.nsi seems to be the one I want. I can't follow the command line construction logic however to see what's the eventual command that it executes. I tried using the task manager to find it, but all I see are 2 setup.exe processes that don't carry much more information.
For the stub installer you will need to skip this
1918   FindWindow $0 "${WindowClass}"
1919   ${If} $0 <> 0 ; integer comparison
1920     StrCpy $FirefoxLaunchCode "1"
1921     MessageBox MB_OK|MB_ICONQUESTION "$(WARN_MANUALLY_CLOSE_APP_LAUNCH)"
1922     Return
1923   ${EndIf}
http://mxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/stub.nsi#1918

For the full installer you will need to skip this
772   ${ManualCloseAppPrompt} "${WindowClass}" "$(WARN_MANUALLY_CLOSE_APP_LAUNCH)"
http://mxr.mozilla.org/mozilla-central/source/browser/installer/windows/nsis/installer.nsi#772

I think the following should accomplish what you want.

add the following to defines.nsi.in
#ifdef DEV_EDITION
!define DEV_EDITION
#endif

and around the blocks mentioned above add
!ifndef DEV_EDITION
  FindWindow $0 "${WindowClass}"
  ${If} $0 <> 0 ; integer comparison
    StrCpy $FirefoxLaunchCode "1"
    MessageBox MB_OK|MB_ICONQUESTION "$(WARN_MANUALLY_CLOSE_APP_LAUNCH)"
    Return
  ${EndIf}
!endif

!ifndef DEV_EDITION
  ${ManualCloseAppPrompt} "${WindowClass}" "$(WARN_MANUALLY_CLOSE_APP_LAUNCH)"
!endif
Flags: needinfo?(robert.strong.bugs)
Another option would be to just add the following to Aurora's branding.nsi
!define DEV_EDITION
OK, all that make sense. I've pushed this patch to gum and will report back when I've tested the resulting builds.
Attachment #8514921 - Flags: review?(robert.strong.bugs)
Assignee: nobody → past
Status: NEW → ASSIGNED
I'm happy to report the patch seems to have fixed the issue!
Attachment #8514921 - Flags: review?(robert.strong.bugs) → review+
https://hg.mozilla.org/mozilla-central/rev/1bf7c3275367
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 36
Comment on attachment 8514921 [details] [diff] [review]
The windows installer shouldn't bypasses the profile selection logic when it tries to launch the installed app

Approval Request Comment
[Feature/regressing bug #]: bug 1024110
[User impact if declined]: launching Aurora from the Windows installer will not work properly
[Describe test coverage new/current, TBPL]: manual testing on m-c, gum
[Risks and why]: this is a minor build-time configuration change
[String/UUID change made/needed]: none
Attachment #8514921 - Flags: approval-mozilla-aurora?
Attachment #8514921 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
I found an issue and I filled bug 1094299.
Verified fixed with latest gum build (buildID: 20141106161710).
Status: RESOLVED → VERIFIED
Status: VERIFIED → RESOLVED
Closed: 5 years ago5 years ago
You need to log in before you can comment on or make changes to this bug.