290704 - [Win32]Command line option -ispf is broken in installers on nightly builds since rebranding for Deer Park.

Status: RESOLVED INVALID

(Firefox :: Installer, defect)

Description

[Tristor]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050416
Firefox/1.0+
I am not 100% sure on which build this started happening, but I think it started
happening on the 20050415 build.

I have a script setup to update my nightlies, both Aviary and Trunk, in a simple
operation, instead of repeating a multitude of commands.  Script has worked fine
for quite awhile now, but recently (I believe after 0415 build) it started
leaving behind traces of running, specifically a new shortcut on the desktop (I
didn't check in other places).  I specify the -ispf installer flag in my script,
so no shortcuts at all should be made anytime during the install process.  I am
not sure what happened prior to the 0415 build, but it appears to have broken
the installer.  For reference, the following is out of the source from lxr:

-ispf: Ignore the [Program FolderX] sections that show\n the Start Menu shortcut
folder at the end of installation.\n

I will attach a copy of the script momentarily.

Steps to Reproduce:

1. Run the script (or make one then run it) that updates your nightly install
using the -ispf flag
2. Wait for the script to finish
3. Observe the creation of a desktop shortcut, when no shortcut should have been
made.

Actual Results:

A desktop shortcut (and possible others) is created contrary to the switches
used when running the installer.  This causes me to do extra cleanup, which
wasn't previously necessary.

Expected Results:

The installer switch works as normal and prevents the creation of shortcuts on
the desktop, in the quicklaunch, and in the start menu.

Comment 1

[Tristor]

Attachment: The script I wrote/use to update my nightly installs.

I will see about making a chopped down version of this script to use as a
testcase shortly.

Comment 2

[Tristor]

Attachment: Testcase (instructions in comment #2)

Steps for Reproduction with testcase:

1. Grab win32.installer.exe
2. Grab this testcase
3. Rename it so it ends in .bat
4. Run it
5. Observe the shortcut that is made, even though the testcase specifies the
-ispf switch
6. Delete the shortcut, installer, testcase, and the directory C:\290704test\

Comment 3

[Tristor]

(In reply to comment #2)
>
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/firefox-1.0+.en-US.win32.installer.exe

is the location of the installer file.

Comment 4

[Tristor]

Well.. that's just fricking beautiful.. I no longer can reproduce this on trunk,
but /Aviary/ started doing it now... *goes to comment out the Aviary portion of
his update script*.  I am going to WFM this... I am not sure what fixed it,
nobody ever commented, bleh.

Comment 5

[Tristor]

(In reply to comment #4)
> Well.. that's just fricking beautiful.. I no longer can reproduce this on trunk,
> but /Aviary/ started doing it now... *goes to comment out the Aviary portion of
> his update script*.  I am going to WFM this... I am not sure what fixed it,
> nobody ever commented, bleh.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050521
Firefox/1.0+

0521 causes this to break again, so I am re-opening.  The shortcut on the
Desktop for it is entitled "Deer Park Alpha 1".  Same testcase applies, same
problem, the switch -ispf for the installer doesn't work.  This is a regression
from something checked in since 0520, so it shouldn't be too hard to figure out
what it is, I will take a glance around.

Comment 6

[Tristor]

This looks like a regression from landing bug 294399 which rebranded Trunk for
Deer Park, was checked in on 0520.

Comment 7

[Mike Connor [:mconnor]]

I can reproduce this with the build in
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-05-19-07-trunk/ so
its not related to the deer park rebranding bug.

the -h switch indicates that this switch is used to "Ignore the [Program
FolderX] section that show the Start Menu shortcut folder at the end of
installation." which refers to the "where in the Start Menu do we put these
shortcuts?" page that isn't in the Firefox installer.

The referenced section doesn't exist in the Firefox Windows installer config,
period, and I think its ignored in the Unix version as well.  Either way, the
switch doesn't do what you think it does, so the entire bug is INVALID.

Comment 8

[Tristor]

(In reply to comment #7)
> I can reproduce this with the build in
> ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2005-05-19-07-trunk/ so
> its not related to the deer park rebranding bug.
> 
> the -h switch indicates that this switch is used to "Ignore the [Program
> FolderX] section that show the Start Menu shortcut folder at the end of
> installation." which refers to the "where in the Start Menu do we put these
> shortcuts?" page that isn't in the Firefox installer.
> 
> The referenced section doesn't exist in the Firefox Windows installer config,
> period, and I think its ignored in the Unix version as well.  Either way, the
> switch doesn't do what you think it does, so the entire bug is INVALID.


-ispf: Ignore the [Program FolderX] sections that show%s the Start Menu shortcut
folder at the end of installation.

What this does it not create any shortcuts on the desktop, quicklaunch, or start
menu, by ignoring the part of the installer program that normally displays
checkboxes giving you the option to not do these things.  It definitely /does/
work normally as I describe, and something (perhaps not Deer Park rebranding)
broke it for 0521.  I did not have this happen when using my update script to
upgrade from 0518 to 0519 or 0519 to 0520, so I haven't had this problem until
0521 Trunk nightly was released.  I still think this has something to do with
Deer Park rebranding, but if you disagree, perhaps you could help me find what
regressed this?  I am re-opening, because the problem does exist, this is not
Invalid, though it may be fixed in an hourly or something and be WFM.

Comment 9

[Tristor]

::testcase for bug 290704

@echo off
cls
"firefox-1.0+.en-US.win32.installer.exe" -ms -f -ira -ispf -dd "C:\290704test\"
:end

This literally reads:  "Install Firefox, don't show the installer (silent),
force overwrite of existing files (force), don't run the app at the end of
installation (ignorerunapp), don't create any shortcuts anywhere (ignore
programfolderx), and stick it in that directory."

Comment 10

[Mike Connor [:mconnor]]

Your assumption about what Program FolderX is and what this switch does are
wrong.  You can wish as hard as you like, but the switch doesn't do anything in
Firefox.  Also, read my comment again.  0519 doesn't do what you think it does
with this switch either, so your regression window is bogus.  You're probably
missing something, but I've looked at the code and it has nothing to do with
what you're talking about.

There isn't even a [Program FolderX] section IN the Windows installer, as I
said, so this is just incredibly bogus.

Comment 11

[Tristor]

(In reply to comment #9)
> ::testcase for bug 290704
> 
> @echo off
> cls
> "firefox-1.0+.en-US.win32.installer.exe" -ms -f -ira -ispf -dd "C:\290704test\"
> :end
> 
> This literally reads:  "Install Firefox, don't show the installer (silent),
> force overwrite of existing files (force), don't run the app at the end of
> installation (ignorerunapp), don't create any shortcuts anywhere (ignore
> programfolderx), and stick it in that directory."

(In reply to comment #10)
> Your assumption about what Program FolderX is and what this switch does are
> wrong.  You can wish as hard as you like, but the switch doesn't do anything in
> Firefox.  Also, read my comment again.  0519 doesn't do what you think it does
> with this switch either, so your regression window is bogus.  You're probably
> missing something, but I've looked at the code and it has nothing to do with
> what you're talking about.
> 
> There isn't even a [Program FolderX] section IN the Windows installer, as I
> said, so this is just incredibly bogus.

Perhaps, but as I said, it's been working consistently for quite a long time, so
if as you say, this switch does nothing in Windows, then perhaps you can
identify which other switch it is that would have that effect?  It is entirely
possible I am wrong, but I have had scripted installs going on 3 months now, and
not only did I understand what I said to be true after reading the source, but I
also was told in IRC that those were the switches to do and what their functions
were.  For quite a while now, with only an occasional breakage (the original
filing of this bug with the 0416 build) did I have any issues with it working.

To be specific, the part of the source I got my information from is
xpinstall/package/build/win/gre/config.it

http://lxr.mozilla.org/seamonkey/source/xpinstall/packager/build/win/gre/config.it#684

Comment 12

[Tristor]

If I know that I have the right flag for that effect that is broken, and that it
works on Windows, I will be more than happy to work my way back through trunk
builds until I find where the problem started occuring.