495684 - [SeaMonkey] Win32 installer leaves UAC.dll in custom temp directory

Status: RESOLVED WORKSFORME

(SeaMonkey :: Installer, defect)

Description

[Steve Snyder]

The installer (2.0b1pre, 31 May 2009 nightly of comm-central-1.9.1) leaves this in my temporary directory on installation:

~\Temp\nsuXX.tmp\UAC.dll

where XX is a random hexidecimal number.  A uniquely-named directory is created each time, so installing 3 times will leave 3 directories behind, each containing that 18KB file UAC.dll.  Given the 2-digit hex number, I guess the user could have up to 255 directories left over from previous SM installations.

On uninstall, this is left behind:

~\Temp\~nsu.tmp\Au_.exe

Given the name of the DLL, I wonder if this is some Vista/Win7 baggage left uninstalled as inappropriate for my Win2K system.

Comment 1

[Serge Gautherie (:sgautherie)]

Can you reproduce with Firefox v3.5b4 / current v3.5(rc1)pre?

Comment 2

[Steve Snyder]

Tested with ~/3.5b99-candidates/build2/win32/en-US/Firefox Setup 3.5 Beta 99.exe on a clean profile.

First installation left no files and no directories remaining.  Uninstallation left a directory named ~nsu.tmp, containing file Au_.exe.

I deleted ~nsu.tmp and it's contents and did a 2nd install.  Again, ~nsu.tmp\Au_.exe was left behind.

For the 3rd installation I left the remnants of the previous installation.  After uninstalling again this same single file & directory remained in my Temp directory.

So, no, there is no growing accumulation of file and directories with Firefox on Win2K.

Comment 3

[Serge Gautherie (:sgautherie)]

So, Au_.exe part is "Core" and UAC.dll part is SeaMonkey only.

http://mxr.mozilla.org/mozilla1.9.1/search?string=UAC%5C.dll&regexp=on&case=on
That's odd, as it looks like this dll would be referenced in common Toolkit only.
(But I don't know much about how the installer works.)

Comment 4

[Steve Snyder]

FYI, this behavior is also seen with the released 2.0b1.

Comment 5

[Robert Kaiser]

I don't see any reason to give this special priority, but it's also not unwanted, so cancelling the wanted flag.

Comment 6

[Robert Kaiser]

Rob, any idea what's happening there?

Comment 7

[Robert Strong (they/them - no direct email)]

I had a discussion a while back in bug 470972 that I suspect is the cause. Basically, the UAC.dll can be used when UAC is not available for some of the buiiltin NSIS functionality but the other installers only load the UAC.dll when they actually need it and use the builtin NSIS functionality instead. I would likely take a patch in bug 470972 on trunk if someone created one.

Comment 8

[Robert Strong (they/them - no direct email)]

Also keep in mind that the SeaMonkey installer could use the methods used by the other installers instead. If you choose to take the route of finding someone to fix bug 470972 then you might also need to patch all installers.

Comment 9

[Robert Strong (they/them - no direct email)]

I'll try to find some time to look into changing SeaMonkey's installer / uninstaller to be like all of the other app's so this doesn't happen. If you don't want me to change SeaMonkey's you can always use your own custom code instead of the common code in common.nsh installer / uninstaller. I'll assign this to myself if / when I have time to create a patch.

Comment 10

[Robert Strong (they/them - no direct email)]

(In reply to comment #0)
>...
> On uninstall, this is left behind:
> 
> ~\Temp\~nsu.tmp\Au_.exe
Both Au_.exe and the ~nsu.tmp directory are deleted on reboot.

Looking into why the UAC dll isn't unloaded for SeaMonkey

Comment 11

[Robert Kaiser]

(In reply to comment #9)
> I'll try to find some time to look into changing SeaMonkey's installer /
> uninstaller to be like all of the other app's so this doesn't happen.

I don't think it's intentional that we differ, we probably just haven't ported some changes that happened in the others - but Frank (mcsmurf) might know more, as he's officially our owner for Windows installer and system integration.

Comment 12

[Robert Strong (they/them - no direct email)]

I found the main cause which I believe is intentionally different since iirc no other app was ever implemented in this manner.
http://mxr.mozilla.org/comm-central/source/suite/installer/windows/nsis/installer.nsi#664

Besides that there are a few changes made to Thunderbird which didn't have to be made for Firefox (no mail handlers in Firefox) that never made it into SeaMonkey that I will likely fix at the same time.

Comment 13

[Robert Kaiser]

(In reply to comment #12)
> I found the main cause which I believe is intentionally different since iirc no
> other app was ever implemented in this manner.
> http://mxr.mozilla.org/comm-central/source/suite/installer/windows/nsis/installer.nsi#664

Not entirely true. You actually did put one branch that way for Thunderbird in bug 404609 and that's what Frank ported to SeaMonkey in bug 453797. If that's wrong, it should be corrected.

> Besides that there are a few changes made to Thunderbird which didn't have to
> be made for Firefox (no mail handlers in Firefox) that never made it into
> SeaMonkey that I will likely fix at the same time.

That would be cool.

Comment 14

[Robert Strong (they/them - no direct email)]

(In reply to comment #13)
> (In reply to comment #12)
> > I found the main cause which I believe is intentionally different since iirc no
> > other app was ever implemented in this manner.
> > http://mxr.mozilla.org/comm-central/source/suite/installer/windows/nsis/installer.nsi#664
> 
> Not entirely true. You actually did put one branch that way for Thunderbird in
> bug 404609 and that's what Frank ported to SeaMonkey in bug 453797. If that's
> wrong, it should be corrected.
Actually, entirely true.

Before the patch from bug 404609:
Function LaunchApp
  ${ManualCloseAppPrompt} "${WindowClass}" "$(WARN_MANUALLY_CLOSE_APP_LAUNCH)"
  Exec "$INSTDIR\${FileMainEXE}"
FunctionEnd

With the patch from bug 404609:
Function LaunchApp
  ClearErrors
  ${GetParameters} $0
  ${GetOptions} "$0" "/UAC:" $1
  ${If} ${Errors}
    ${ManualCloseAppPrompt} "${WindowClass}" "$(WARN_MANUALLY_CLOSE_APP_LAUNCH)"
    Exec "$INSTDIR\${FileMainEXE}"
  ${Else}
    GetFunctionAddress $0 LaunchAppFromElevatedProcess
    UAC::ExecCodeSegment $0
  ${EndIf}
FunctionEnd

Function LaunchAppFromElevatedProcess
  ${ManualCloseAppPrompt} "${WindowClass}" "$(WARN_MANUALLY_CLOSE_APP_LAUNCH)"

  ; Find the installation directory when launching using GetFunctionAddress
  ; from an elevated installer since $INSTDIR will not be set in this installer
  ReadRegStr $0 HKLM "Software\Clients\Mail\${ClientsRegName}\DefaultIcon" ""
  ${GetPathFromString} "$0" $0
  ${GetParent} "$0" $1
  ; Set our current working directory to the application's install directory
  ; otherwise the 7-Zip temp directory will be in use and won't be deleted.
  SetOutPath "$1"
  Exec "$0"
FunctionEnd

What SeaMonkey implemented:
Function LaunchApp
  GetFunctionAddress $0 LaunchAppFromElevatedProcess
  UAC::ExecCodeSegment $0
FunctionEnd

Function LaunchAppFromElevatedProcess
  ${ManualCloseAppPrompt} "${WindowClass}" "$(WARN_MANUALLY_CLOSE_APP_LAUNCH)"
  ; Find the installation directory when launching using GetFunctionAddress
  ; from an elevated installer since $INSTDIR will not be set in this installer
  ${StrFilter} "${FileMainEXE}" "+" "" "" $R9
  ReadRegStr $0 HKLM "Software\Clients\StartMenuInternet\$R9\DefaultIcon" ""
  ${GetPathFromString} "$0" $0
  ${GetParent} "$0" $1
  ; Set our current working directory to the application's install directory
  ; otherwise the 7-Zip temp directory will be in use and won't be deleted.
  SetOutPath "$1"
  Exec "$0"
FunctionEnd

I have no problem helping out SeaMonkey (I actually think it is a good thing to do) and I want SeaMonkey to be successful but when SeaMonkey does things differently bugs like this are going to happen just like what happened in bug 553890 and its related bugs. Just as SeaMonkey would like to be informed of changes (something that I think I have done a pretty damn good job of by cc'ing the appropriate people and filing bugs often with patches) when SeaMonkey chooses to do things differently the very least that can be done is informing the appropriate people.

Comment 15

[Robert Strong (they/them - no direct email)]

I'm not going to have any time to spend on this. Comment #14 provides more than enough detail on what needs to happen to fix this bug.

Comment 16

[Robert Kaiser]

mcsmurf, are we still supposed to do anything here?

Comment 17

[Philip Chee]

mcsmurf says over IRC:
"You can resolve Bug 495684 as wfm, I cannot reproduce this on WinXP (reported used 2K, so also a non-UAC OS)"