Closed Bug 245392 Opened 20 years ago Closed 19 years ago

Installer options for shortcuts don't work (update/install adds unwanted icons to desktop/quick launch, creates empty folder in start menu)

Categories

(Firefox :: Installer, defect, P3)

Product:
Firefox
Component:
Installer
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox1.5

People

(Reporter: bugzilla, Assigned: benjamin)

References

Details

(Keywords: fixed1.8)

Attachments

(4 files, 5 obsolete files)

Patch against trunk (checked in)
2.61 KB, patch
dveditz
: review+
Details | Diff | Splinter Review
Use RegCreateKeyEx consistently
3.23 KB, patch
dveditz
: review+
mscott
: approval1.8rc1+
Details | Diff | Splinter Review
Regmon log file
1.84 KB, text/plain
Details
Regmon log file
1.84 KB, text/plain
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040602 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2) Gecko/20040602 Firefox/0.8.0+

Using the new options to control where icons are installed did not work as expected.

Reproducible: Always
Steps to Reproduce:
1. Do a custom install
2. Choose options to install icons on the desktop and in the Start menu.
Actual Results:  
No icon was placed on the desktop.  A Mozilla Firefox folder was put in the
Start menu, but with no icons in it.

Expected Results:  
Icons on the desktop and Start menu.
Flags: blocking1.0?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040603
Firefox/0.8.0+

also on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040603
Firefox/0.8.0+

Description:
Selecting not to install shortcuts on the Start Menu, the installer puts an
empty Mozilla Firefox Folder there anyway.

Reproducable: Always
Expected Result: No Folders or Icons In Start Menu
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2)
Gecko/20040602 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8a2)
Gecko/20040602 Firefox/0.8.0+

Using the new options to control where icons are installed did not work as expected.

Reproducible: Always
Steps to Reproduce:
1. Do a custom install
2. Choose options to install icons on the desktop and in the Start menu.
Actual Results:  
No icon was placed on the desktop.  A Mozilla Firefox folder was put in the
Start menu, but with no icons in it.

Expected Results:  
Icons on the desktop and Start menu.
Can't replicate in 20040604 build, resolving bug.
Status: NEW → RESOLVED
Closed: 20 years ago
Flags: blocking1.0?
Resolution: --- → WORKSFORME
Actually, it turns out I am still replicating problems with this.

I just tried an install putting no icons anywhere, and got a Start Menu folder
filled with the usual icons anyway.

20040604
Status: RESOLVED → REOPENED
Flags: blocking1.0?
Resolution: WORKSFORME → ---
*** Bug 245694 has been marked as a duplicate of this bug. ***
Summary: Options for where to put icons not always working → Installer options for where to put icons (start menu / desktop) not always working
I chose to not install icons anywhere.  I still got a start menu folder.
Flags: blocking0.9?
*** Bug 245393 has been marked as a duplicate of this bug. ***
0.9RC doesn't seem to make a Desktop icon (Win2k) even with the defult install -
v. odd.
It doesn't make a desktop icon because, I was told, that was what the WinXP HIG
recommended.
Status: REOPENED → ASSIGNED
So the box should be unchecked by default, but if someone does check it, it
should install the shortcut.
*** Bug 246339 has been marked as a duplicate of this bug. ***
No matter what I've ever chosen, the installer always does the default actions.
It creates a quicklaunch icon and program group, even though I uncheck the
options every bloody time.
*** Bug 246486 has been marked as a duplicate of this bug. ***
I just installed Firefox 0.9 final and selected to create icons only in Start
menu. But Firefox installer created them also in QuickLunch and on desktop.
I just installed Firefox 0.9 final and selected to create icons only in Start
menu. But Firefox installer created them also in QuickLunch and on desktop.
Flags: blocking0.9?
Flags: blocking1.0? → blocking1.0+
*** Bug 247750 has been marked as a duplicate of this bug. ***
*** Bug 247883 has been marked as a duplicate of this bug. ***
Priority: -- → P3
Target Milestone: --- → Firefox1.0beta
*** Bug 249043 has been marked as a duplicate of this bug. ***
*** Bug 249131 has been marked as a duplicate of this bug. ***
To reduce the amount of dupes, "shortcut" should probably be added to the
summary of this bug. Three of the dupes included it in the summary, and most
refer to them as "shortcut icons". Quick launch should be added for completeness.

Ex:
Installer options for where to put shortcut icons (start menu / desktop / quick
launch) not always working
Summary: Installer options for where to put icons (start menu / desktop) not always working → Installer options for where to put shortcut icons (start menu / desktop / quick
Summary: Installer options for where to put shortcut icons (start menu / desktop / quick → Installer options for where to put shortcut icons (start menu / desktop / quick launch)
I also think that no shortcuts should be installed by default if it's an 
update/upgrade, because the shortcuts should already be in place and otherwise 
the user has to adjust the options every time he updates/upgrades.
(In reply to comment #21)
> I also think that no shortcuts should be installed by default if it's an 
> update/upgrade, because the shortcuts should already be in place and otherwise 
> the user has to adjust the options every time he updates/upgrades.

Offering to install the shortcuts by default seems to be industry standard.
Assignee: bugs → dveditz
Status: ASSIGNED → NEW
As of 0.9.2 unchecking all of the options, whether to have shortcuts on the
Quickstart, Desktop, or start menu, have no effect. Shortcuts are placed anyway.
There seems to be 2 browser.jst file. One in mozilla/browser/installer/windows
and another in mozilla/xpinstall/packager/build/win/mozilla/XPI_JSTs
The first one creates shortcuts like this:

    // Create the Shortcuts
    winreg.setRootKey(winreg.HKEY_CURRENT_USER);
    subkey              =
"SOFTWARE\\$CompanyName$\\$ProductName$\\$UserAgent$\\Main";
    if (winreg.getValueNumber(subkey, "Create Desktop Shortcut") != 0)
      File.windowsShortcut(fileExe, fFolderDesktop, scExeDesc, fProgram, "",
fileExe, 0);

so as you see there is a "if" checking the user's choice.

Here is the same line but from 
mozilla/xpinstall/packager/build/win/mozilla/XPI_JSTs/browser.jst


    /* create the shortcuts */
    File.windowsShortcut(fileExe, fFolderDesktop, scExeDesc,     fProgram,  "",
                fileExe, 0);
    File.windowsShortcut(fileExe, fFolderPath,    scExeDesc,     fProgram,  "",
                fileExe, 0);

The shortcuts are just created...

Could it be this?
2 files that seems to do the same thing:
mozilla\xpinstall\packager\build\win\mozilla\XPI_JSTs\browser.jst
(the one attached, with line 157 to 179 modified)
and
mozilla\browser\installer\windows\browser.jst
which seems to be an updated one. Maybe the installer is just looking in the
first file for installation but changes have been made in the second one...
Attachment #154121 - Flags: review+
Attachment #154121 - Flags: review+ → review?
Comment on attachment 154121 [details]
File that seems to create the shortcuts in the installation

That's not to pass a review because:

You haven't specified who should review it.
It's a complete file, not a diff, so it can't stand as a patch or be checked
into CVS as is.
Attachment #154121 - Flags: review?
Flags: blocking-aviary1.0RC1?
*** Bug 253276 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
Shouldn't this one go in as "bugs:  	blocking-aviary1.0PR"?

I would think this would be a good one to get in asap before the RC's start
coming around.
*** Bug 254429 has been marked as a duplicate of this bug. ***
*** Bug 254644 has been marked as a duplicate of this bug. ***
*** Bug 255634 has been marked as a duplicate of this bug. ***
*** Bug 257417 has been marked as a duplicate of this bug. ***
    if(!File.exists(fDefShortcuts))
      File.dirCreate(fDefShortcuts);

should be done within the block a few lines below which checks if the user
wanted to install the start menu items:

    if (winreg.getValueNumber(subkey, "Create Start Menu Shortcut") != 0) {
    if(!File.exists(fDefShortcuts))
      File.dirCreate(fDefShortcuts);

should be done within the block a few lines below which checks if the user
wanted to install the start menu items:

    if (winreg.getValueNumber(subkey, "Create Start Menu Shortcut") != 0) {
This should fix the empty start menu folder bug. Testing would be appreciated.
Comment on attachment 157929 [details] [diff] [review]
Fix bug that creates the empty start menu folder

The start menu folder was always created explicitly by the installer, so that
the uninstaller would know to remove it. This checks to make sure that the user
chose start menu icons before creating the folder.
Attachment #157929 - Flags: review?(bugs)
*** Bug 258609 has been marked as a duplicate of this bug. ***
Tweaking summary.
Summary: Installer options for where to put shortcut icons (start menu / desktop / quick launch) → Installer options for where to put start menu / desktop / quick launch shortcut icons (empty folder created, user selections ignored)
*** Bug 259290 has been marked as a duplicate of this bug. ***
*** Bug 259357 has been marked as a duplicate of this bug. ***
why does it create a folder at all? 
IMO icons should be directly in startmenu/programs - not in a subfolder. 
all MS and adobe apps do this and its far more sensible than cluttering
everything up. 

plus having a folder for just one icon is insane and just lengthens the time
taken to load it up. 

it also hides the pretty and recognisable icon until you actually find and open
the "mozilla firefox" subfolder in your startmenu.
I have MS Office 2003 installed and it correctly creates a special folder for
its icons. I think I was reading some MS document some day that instructed
application developers to create a special folder for all icons if there are
more icons and only if there is only one icon then it should go directly to the
Programs folder. I also think it is much cleaner to create a special folder.
Just imagine what would happen if all apps created 10 shortcuts each in Start
Menu. It would be a total mess and it would be even harder to find the desired
app. I also think that if all the shortcuts would have to be opened it would
take more time then to just show few folders.
What would be great is if the application folder could have its own icon, like
it is possible in KDE or GNOME in Linux. Then you could quickly find the right
application subfolders with all the application shortcuts. Is this possible to
do in Windows?
(In reply to comment #42)

i agree if there's more than one icon its ok, for some reason i thought mozilla
only made one. i wasnt suggesting ff should spam your start menu with lots of
things whose name doesn't even indicate a link to firefox.

but i still think the firefox icon should go directly in the start menu/programs
- especially something so frequently used as a web browser.

maybe the installer should have a seperate option for the
readmes/profilemanager. i dont use these and i cant imagine that a high
percentage of other users do either.
On windows XP Firefox already gets a special place of prominance on the Start
Menu if you've made it your default browser.
(In reply to comment #43)

yeah you can do this.

i'm not sure this is a good idea on windows as it's not exactly standard.

clicking the menu name itself won't launch the application, it'll just pop up
the sub menu which may confuse some users. it would be nice if hovering would
pop up the submenu of options and clicking the menu directly opens the
application - but i don't think this is possible.

example pic : http://www.olliholliday.co.uk/pics/firefoxfolder.png


windows even has a UI for it, right click the folder choose properties. go to
customise and the option's in there. 
(despite what it says, it doesn't actually change the icon of every folder) 
this just creates a Desktop.ini file in the folder, with the system attribute.
*** Bug 259663 has been marked as a duplicate of this bug. ***
MS Windows places the icons for Internet Explorer and Outlook Explorer directly
into the Start Menu -> Programs, without creating any subfolders. Mozilla
Firefox is planed to be the IE killer (or replace) and so should be also placed
to Programs directly. 
Another (related?) problem:

Reproducible: Always
Steps to Reproduce:
1. Do a custom install
2. Among the 3 choices, clear "Desktop" and "Start Menu", and only select "Quick
Launch Toolbar" only
Actual Results:  Quick Launch Toolbar icon created as expected. Empty folder
created in Start Menu.
Expected Results: No empty folder.

(In reply to comment #49)
> Another (related?) problem:
> 
> Reproducible: Always
> Steps to Reproduce:
> 1. Do a custom install
> 2. Among the 3 choices, clear "Desktop" and "Start Menu", and only select "Quick
> Launch Toolbar" only
> Actual Results:  Quick Launch Toolbar icon created as expected. Empty folder
> created in Start Menu.
> Expected Results: No empty folder.
> 

That would be why "empty folder created" is part of the bug summary.
On my computer, all installed browsers have their shortcuts in Start
Menu/Programs/Internet/Browsers. For Firefox, I can not tell where it should put
its icons, which I'd like to see fixed, because moving the shortcuts everytime I
install a nightly is becoming a bit of a bother :). Currently I just tell it to
not create any start menu entries at all (but then again, that doesn't work
either -_-;;). The downside of this is that if I would ever want to uninstall
Firefox (which is a rediculous notion I guess ;p) it will not automatically
remove its Start menu shortcuts.

As for placing the icons in the root of the Start/Programs folder - as said
before, on Windows XP at least Firefox and Thunderbird are featured very
prominently in the Start menu, so I see no need to clutter the Start menu and
removing any kind of organization by placing those shortcuts in to root of
programs (two for both FF and TB, makes 4 in total). Being an IE killer doesn't
mean it has to do everything IE does, if you ask me.

Aside from the 'Internet' link in the XP Start menu, Firefox also adds links on
the two other most-used shortcut locations - the quicklaunch and the desktop.
All three of these are used much more commonly as an access point than the
contents of program files is. Well, I think I made it clear I strongly object
against the notion of not placing the icons in a (preferably user-selecteable)
folder.

But, who am I :).


~Grauw
(In reply to comment #51)

from a UI perspective, why does firefox even need more than one icon? 

the profile manager isn't something that's used by the vast majority of users,
and ideally it'd be built directly into firefox instead of being a seperate
application anyway. firefox doesn't take long to load, changing profiles from
the file menu wouldn't be a problem. 

as for readmes, nobody reads them and a well designed application shouldn't need
them anyway - the one included atm is just 3 lines pointing to a URL.
the license is included in the installer and available in the installation
folder and so doesn't need an icon in the start menu.

any further information should be provided on a website (maybe accessible from
the help menu) in a far more readable and sensibly organised format than plain
text. 


as for the argument that it doesn't matter, as XP already has an icon for the
current default browser - this is only if using the newstyle XP start menu
(which plenty of people don't use), it's not on the classic version and (dont
quote me on this) i imagine it's not on the win2k start menu either. 

either way, saying that you can have one set of icons overly complicated because
there's already another simpler one somewhere else is a bit daft - each set
should be as simple as possible to suit everybody's tastes/habits. 



as an aside, i have a lot of applications loaded and the standard practice of
each one creating its own folder is just ridiculous. especially when it starts
with the wrong letter - if you download a browser called "firefox" then thats
what people are going to look for, n00bs won't necessarily know to look for mozilla.
This bug is not about whether what the installer currently does (or will do when
the bug is fixed) is appropriate.  It's simply about getting the installer to
correctly place or not place icons/folders as asked to during the installation.

Please take issues on whether there should be a Start menu folder ever, or what
to name it, etc. to a new bug.

Don't morph the intent of this bug, as the patch for this bug obviously does not
address those issues.  Nor should it, really.
*** Bug 256566 has been marked as a duplicate of this bug. ***
From duplicate (questionable imho) bug 256566:

When installing as Administrator on a Windows machine, Firefox is installed for
all users (creating Desktop/Start Menu icons for all users).

This behaviour should be customisable. A
"Install for:
  [ ] Current User
  [x] All Users (need administrator rights)"
would do the job.

When current user install, icons and stuff go to user-profile-path instead of
"Default User".

See also bug 28174 for Browser-product of Mozilla.
Blocks: 259394
(In reply to comment #22)
> (In reply to comment #21)
> > I also think that no shortcuts should be installed by default if it's an 
> > update/upgrade, because the shortcuts should already be in place and otherwise 
> > the user has to adjust the options every time he updates/upgrades.
> 
> Offering to install the shortcuts by default seems to be industry standard.

Yes, but in my opinion a bad standard.
*** Bug 260598 has been marked as a duplicate of this bug. ***
*** Bug 261180 has been marked as a duplicate of this bug. ***
*** Bug 261763 has been marked as a duplicate of this bug. ***
Not a blocker.
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
It looks unprofessional not to fix this (and the blocked bug), but it's your
decision and only my 2 cents.
There should be a new field for bugzilla where these can be put into the next
version as blockers.

That said, I can't believe this one was let go.
*** Bug 262167 has been marked as a duplicate of this bug. ***
*** Bug 262857 has been marked as a duplicate of this bug. ***
Patch to fix bug that creates empty folder even if a user does not select to
create icons in Start Menu Programs folder.
Comment on attachment 161265 [details] [diff] [review]
don't create empty Start Menu folder

the wrong subkey was being used
Attachment #161265 - Flags: review?(bryner)
Both patches here seem to have a few problems. The first is bitrotten and the
second does not fix the problem completely. I will attach another patch shortly.
Attachment #157929 - Attachment is obsolete: true
Attachment #157929 - Flags: review?(bugs)
Attachment #161265 - Attachment is obsolete: true
Attachment #161265 - Flags: review?(bryner)
Attached patch Patch attempt #2 (obsolete) — — Splinter Review 
This just adjusts a few of the changes made by ben in bug 247884.  Should fix
the blank folder bug.
Attachment #154121 - Attachment is obsolete: true
(I don't think this adds much new information, other than to confirm it still
isn't working in the current release.)

I just installed "Firefox Setup 1.0PR.exe" on Windows NT:

Mozilla/5.0 (Windows; U; WinNT4.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

using the "custom" option, and observed:

1. the option to create a shortcut on the desktop was checked by default
(supposedly in against recommendations mentioned in bug 225641 Comment #6).

2. After unchecking that option, the installer still created a new desktop icon.

(In reply to comment #69)

> Mozilla/5.0 (Windows; U; WinNT4.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

The patch for bug 247884 that fixes the installer options was checkin on
2004-10-03 19:00. You'll need to get a later build to verify.

Gavin:
Why do you always creating the default shortcuts folder?
(In reply to comment #69)

> Mozilla/5.0 (Windows; U; WinNT4.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

The patch for bug 247884 that fixes the installer options was checkin on
2004-10-03 19:00. You'll need to get a later build to verify.

Gavin:
Why do you always create the default shortcuts folder?
The "default shortcuts" folder, if you observe the code above, is the shortcut
folder in the Firefox installation folder and has nothing to do with the Start Menu.

Looking at the changes made by the checkin for bug 247884, I don't think that
the changes would make a difference, since as you noticed, the subkey is still
set to the previous one. My patch fixes the problem and corrects the behaviour.
(In reply to comment #72)

You're right. The code does use the default shortcut folder later without
checking, so it should always be created. Although, I personally don't see why
we create them if the user decides not to install shortcuts.

I've tested the latest nightly and other than the empty start menu folder, the
installer no longer ignores user options.

Re: Patch attempt #2

To be consistent,
+    if(!File.exists(fDefShortcuts))

should be 
+    if (!File.exists(fDefShortcuts))

Lastly, is bugs@bengoodger.com a valid account to get review from? (I always
thought it was a dummy account)
If 254429 and other's have been marked as duplicates of this bug then,
statements like "I've tested the latest nightly and other than the empty start
menu folder, the installer no longer ignores user options." suggest that the
issue is not yet fully fixed. Or one of those bugs should still be open to
resolve the "empty start menu folder" issue.

Thorin
(In reply to comment #73)
> You're right. The code does use the default shortcut folder later without
> checking, so it should always be created. Although, I personally don't see why
> we create them if the user decides not to install shortcuts.

Eh, it's useful to some, and it will probably not ever be seen by about 98% of
users.

> Re: Patch attempt #2
> 
> To be consistent,
> +    if(!File.exists(fDefShortcuts))
> 
> should be 
> +    if (!File.exists(fDefShortcuts))

Yeah, there are about an equal number of "if (" than there are of "if(" in that
file, so that's not much of an issue.

> Lastly, is bugs@bengoodger.com a valid account to get review from? (I always
> thought it was a dummy account)

That's Ben's bugzilla account, not a dummy account (gotta watch what you're
saying there ;).
(In reply to comment #74)
> If 254429 and other's have been marked as duplicates of this bug then,
> statements like "I've tested the latest nightly and other than the empty start
> menu folder, the installer no longer ignores user options." suggest that the
> issue is not yet fully fixed. Or one of those bugs should still be open to
> resolve the "empty start menu folder" issue.

We know that it's not fully fixed, that's why this bug is still open and there
is a patch submitted. The remaining issue is the empty start menu folder.
Summary: Installer options for where to put start menu / desktop / quick launch shortcut icons (empty folder created, user selections ignored) → Installer options for where to put start menu / desktop / quick launch shortcut icons (empty folder created)
Ok sorry if I sounded um "snarky" or anything I just wanted to make sure that
last (and important part) wasn't being missed or put off as a seperate issue.
(In reply to comment #75)

> That's Ben's bugzilla account, not a dummy account (gotta watch what you're
> saying there ;).

Ok. The reason why I asked was that the original patch had been awaiting review
for over a month. Maybe it'll get through quicker with a less busy reviewer?
Re-requesting blocking-aviary1.0 as one of the most important parts of the
conversion for new users is the install, and this really is something we should
get right. My patch is a simple fix that shouldn't take long to review and
approve but would make a fairly important fix to the installer IMO.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
Whiteboard: [have patch] - need review ben
This bug is there as long as I know firefox ... I always select NOT to install
shortcuts anywhere
but everytime an empty folder is put into startmenu
this is very annoying and should be very easy to fix !

i am on XP
this problem is there since 0.8 till todays build

Mertsch
Flags: blocking-aviary1.0? → blocking-aviary1.0-
This is very annoying.. I have my start menu sorted (Firefox is in Internet >
Browsers > Firefox) thus I don't want another copy of the Firefox folder in my
start menu, I uncheck it and I get an empty folder.. +vote for me :)
bug 246779 is related, but not exactly a duplicate.  
could you possibly address 246779 concurrently with fixing this one?
I can confirm that your patch fixes the bug Gavin...maybe you should try another
Firefox reviewer, like bryner or Blake, since Ben doesn't seem to have time to
check this out.
Comment on attachment 161282 [details] [diff] [review]
Patch attempt #2

Let's try Blake. This is Ben's work I believe, but the patch is simple.
Attachment #161282 - Flags: review?(bugs) → review?(firefox)
*** Bug 265791 has been marked as a duplicate of this bug. ***
blocker 1.0
Flags: blocking-aviary1.0- → blocking-aviary1.0+
Only aviary peers can set blocking +/- flags.. Everybody else should nominate ?
the flag for a peer ro grant or deny. :-)
Flags: blocking-aviary1.0+
Back to the original blocking-aviary1.0-
Flags: blocking-aviary1.0-
I just installed Firefox 1.0 RC1, choosing custom install and deselecting the
"Desktop Icon". However, the installer did put an icon on the desktop. It seems
it still does not obey the user commands. 

In short: Still not fixed.
(In reply to comment #89)
> In short: Still not fixed.

Please don't spam the bug with things we already know.  This bug clearly has no
patch checked in for it, so how would it be fixed?

And it is marked as a minus blocker for 1.0.  So this may or may not be fixed
for 1.0.
How can this not block 1.0? How can you even claim to have a "final" release
when something as simple as the installer can't even work right?

On top of that, there's a patch ready that simply needs a review and this would
be fixed.
*** Bug 266606 has been marked as a duplicate of this bug. ***
I concur whole heartedly with comment #91. Releasing a product OpenSource or not
with a busted installer is sloppy.
*** Bug 266768 has been marked as a duplicate of this bug. ***
*** Bug 266887 has been marked as a duplicate of this bug. ***
upgrading from both the PRrc, and RC1, to the nightly build "Mozilla/5.0 
(Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041101 Firefox/1.0RC2" 
still generates all the posted errors.
(In reply to comment #96)
> upgrading from both the PRrc, and RC1, to the nightly build "Mozilla/5.0 
> (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041101 Firefox/1.0RC2" 
> still generates all the posted errors.

See comment 90.
(In reply to comment #97)
> See comment 90.

"This bug clearly has no
patch checked in for it, so how would it be fixed?" Um, there are four patches
checked in, so that comment is irelivent and "Spamming the bug".
Actually, no, none of these patches has been checked in. They haven't even been
reviewed or approved. The fact that they are posted here in Bugzilla for review
has no bearing on whether they have been applied to the code so that they show
up in Mozilla builds.

Comment 90, among others, stands: the bug has not been fixed, so of course it
still shows itself. Please, no more confirmations are necessary.
*** Bug 267624 has been marked as a duplicate of this bug. ***
*** Bug 268317 has been marked as a duplicate of this bug. ***
Milestone needs to be changed to 1.1 now that 1.0 is coming out.
Target Milestone: Firefox1.0beta → Firefox1.1
I still have this problem with win2k, I choose non shortcuts, but got an empty
folder in my start menu
I don't know if it makes any difference but the ThunderBird installer has this
problem as well. (Were they written by the same person?)
*** Bug 268594 has been marked as a duplicate of this bug. ***
I posted bug 268594, which has just been marked as a dupe of this one.

So, to be clear: I do NOT get an empty folder in the start menu. I get a folder
with Firefox and Firefox (safe mode) links in it.


Also, I did see this bug before filing 268954 - but neither the title nor the
initial report said anything about start menu folders & links being created when
the installer is told not to create them.
(In reply to comment #106)
> I posted bug 268594, which has just been marked as a dupe of this one.
> 
> So, to be clear: I do NOT get an empty folder in the start menu. I get a folder
> with Firefox and Firefox (safe mode) links in it.

Confirming.. something must have changed, as it use to create an empty folder,
but with the 1.0 Release today it does as described above. So now it looks like
the function is compltely non-functional.
Attached patch Patch #2 (whitespace fix) (obsolete) — — Splinter Review 

        Attachment #161282 -
        Attachment is obsolete: true
OS: Windows 2000 → Windows XP
Version: unspecified → 1.0 Branch

    
    

    
  
*** Bug 268748 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 269047 has been marked as a duplicate of this bug. ***

    
    

    
  
Now that Aviary branch is closed, what happens to this bug? It is marked as a
branch bug. Does it exist in trunk? Or will something else have to happen to
trunk before this bug can get fixed there?

    
    

    
  
(In reply to comment #111)
> Now that Aviary branch is closed, what happens to this bug? It is marked as a
> branch bug. Does it exist in trunk?

It exists in the trunk.
Version: 1.0 Branch → Trunk

    
    

    
  
*** Bug 270795 has been marked as a duplicate of this bug. ***

    
    

    
  
I don't see an explicit distinction between Windows versions in the comments
above, so this might help -- when I install Firefox 1.0 in Windows 2000 and
uncheck all options, it just creates an empty Firefox folder in my Start menu
(my Firefox is in Start > Programs > Internet... I always reorganize my shorcuts
into larger categories so I don't have 500 default folders installed by various
apps).   When I uncheck all options in Windows 98 SE, the installer still
creates the whole Start menu folder and desktop icon.

    
    

    
  
*** Bug 272777 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 268732 has been marked as a duplicate of this bug. ***

    
    

    
  
Where's Blake Ross? And why were we assigned Daniel Veditz? Nothing's going to
get done. He hasn't even commented on progress OR likelihood of a target
milestone [aside from Gavin Sharp's which I'd like to believe but if they won't
even review his work AND he's on the team... :( Sentiments are much more
disappointed than that smiley) MUCH LESS reviewed the patches!!! 

Look this bug is driving me up the walls. I took the effort to uncheck the
"Desktop Icon" option everytime. The least you can do is make sure the installer
fulfils that desire. Thanks for trying Gavin. But from the looks of what I've
been seeing a trend of, Gavin and Jon Henry (And I wanna say Josh Powell?) you
guys are not respected by (some of) your fellow teammates when you have offered
worthy commentary/advice and work.

Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8a6) Gecko/20041215 Firefox/1.0+

    
    

    
  
Since development is now back on the trunk, the patch would not be applicable as
written anymore since it's diffed against the relevant Aviary branch files.  It
will have to be ported to the trunk.

    
    

    
  
Also, the team will be taking a break after the release of Seamonkey 1.7.5.

See http://weblogs.mozillazine.org/asa/archives/007089.html

    
    

    
  
Comment on attachment 165311 [details] [diff] [review]
Patch #2 (whitespace fix)

(In reply to comment #118)
> Since development is now back on the trunk, the patch would not be applicable as
> written anymore since it's diffed against the relevant Aviary branch files.  It
> will have to be ported to the trunk.

Actually, the patch as it is applies just fine against the trunk. I'll try
mconnor for review.

        Attachment #165311 -
        Flags: review?(bugs) → review?(mconnor)

    
    

    
  


  
Erg. Spoke too soon. Here's an updated patch.

        Attachment #165311 -
        Attachment is obsolete: true

        Attachment #169044 -
        Flags: review?(mconnor)

    
    

    
  
Comment on attachment 169044 [details] [diff] [review]
Patch against trunk (checked in)

r=dveditz

        Attachment #169044 -
        Flags: review?(mconnor) → review+

    
    

    
  
Could someone with CVS access check this in please? I haven't seen it land, my
apologies if it already has.
Whiteboard: [have patch] - need review ben → checkin-needed

    
    

    
  
*** Bug 275984 has been marked as a duplicate of this bug. ***

    
    

    
  
Comment on attachment 169044 [details] [diff] [review]
Patch against trunk (checked in)

Checking in mozilla/browser/installer/windows/browser.jst;
/cvsroot/mozilla/browser/installer/windows/browser.jst,v  <--  browser.jst
new revision: 1.15; previous revision: 1.14
done

    
  
Whiteboard: checkin-needed

    
    

    
  
This should be now fixed on trunk. Please reopen if any issues remain.
Status: NEW → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED

    
    

    
  
*** Bug 276861 has been marked as a duplicate of this bug. ***

    
    

    
  
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8a6) Gecko/20050104 Firefox/1.0+

Per anyone else's ability to back this up, the problem continues (Desktop icon
appears when I deselect it, Mozilla folder appears fine in Start Menu w/ icons;
would like to assume unchecking it also forces creation).

Hoping others can confirm before a reopen.

    
    

    
  
I think this "fix" has actually made it worse.  I just installed the latest
nightly, and de-selected all three checkboxes.  Instead of creating nothing, as
the fix should have made it do, it actually did more than prior bugginess and
placed shortcuts on my Desktop, in my Quick Launch, AND in my Start Menu.  I
tested this with a nightly from yesterday, and just tested again with
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8a6) Gecko/20050105 Firefox/1.0+.

    
    

    
  
My own testing has shown that the start menu folder is in fact still being
created regardless of the user preference, although I fail to see why.

I'm going to try to spend some time on this in the next week or so. A quick scan
of the logic doesn't seem to show anything obvious, unfortunately.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8b) Gecko/20050115 Firefox/1.0+

Gavin, any luck after doing your tests on finding the fault?

    
  
Flags: blocking-aviary1.1?

    
    

    
  
*** Bug 267730 has been marked as a duplicate of this bug. ***

    
  
Blocks: 256566

    
  
No longer blocks: 259394

    
    

    
  
This is fixed on WinXP. Should OS be changed to WinMe?

    
    

    
  
(In reply to comment #133)
> This is fixed on WinXP. Should OS be changed to WinMe?

This appears to again be a problem on Windows XP with the Firefox 1.0.1
installer.  I've seen it on 5 different workstations today: three were upgrading
from Firefox 1.0, the other two were first time installs.

    
    

    
  
(In reply to comment #133)
> This is fixed on WinXP. Should OS be changed to WinMe?

This problem still exists in version 1.0.1 on Windows XP - I've just installed
Firefox and chose to have no icons/folders created.  Nonetheless, Firefox
created a blank folder in the start menu.  


    
    

    
  
That is because this was fixed on the Trunk, and Firefox 1.0.1 is still released
from the Aviary branch Firefox 1.0 was released from as well.

I don't think there's much chance for this fix to land on the Aviary branch as
well, as it is not really important and not worth the risk/effort.

~Grauw

    
    

    
  
*** Bug 283956 has been marked as a duplicate of this bug. ***

    
    

    
  
(In reply to comment #136)
> That is because this was fixed on the Trunk, and Firefox 1.0.1 is still released
> from the Aviary branch Firefox 1.0 was released from as well.
> 
> I don't think there's much chance for this fix to land on the Aviary branch as
> well, as it is not really important and not worth the risk/effort.
> 
> ~Grauw

...if you don't consider reducing confusion about your only released product
important...

    
    

    
  
> ...if you don't consider reducing confusion about your only released product
> important...

I agree, the whole FF community wants to see more and more users yet we continue
to leave the most glaring and in your face annouying and easily fixed bugs in
the package. It's going to be hard to gain marketshare (er whatever you wanna
call it) if we leave messy things like this in.

    
    

    
  
*** Bug 284248 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 284561 has been marked as a duplicate of this bug. ***

        Attachment #169044 -
        Attachment description: Patch against trunk → Patch against trunk (checked in)

    
  
Depends on: 280195

    
  
No longer depends on: 280195

    
    

    
  
*** Bug 285902 has been marked as a duplicate of this bug. ***

    
  
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0-

    
  
Blocks: 283676

    
  
No longer blocks: 283676

    
    

    
  
(In reply to comment #136)
> That is because this was fixed on the Trunk, and Firefox 1.0.1 is still released
> from the Aviary branch Firefox 1.0 was released from as well.
> 
> I don't think there's much chance for this fix to land on the Aviary branch as
> well, as it is not really important and not worth the risk/effort.
> 
> ~Grauw

So what version will we expect the fix to appear in? I notice that the 1.0.2
installer also creates the empty folder that has been complained about ad
infinitum in this thread, compounded with the dropping of a zip package option
this makes Firefox even more of a hassle to deploy.



    
    

    
  
You could nominate it for 1.0.3... If the people in charge agree, they can + it.

    
  
Flags: blocking-aviary1.0.3?

    
    

    
  
*** Bug 288310 has been marked as a duplicate of this bug. ***

    
    

    
  
We're not taking changes for Aviary 1.0.x other than security fixes and
regressions along the Aviary 1.0.x series (i.e., regressions from security fixes).
Flags: blocking-aviary1.0.3? → blocking-aviary1.0.3-

    
    

    
  
*** Bug 290477 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 290578 has been marked as a duplicate of this bug. ***

    
    

    
  
This issue persists in version 1.0.3

    
    

    
  
Strange, because I just upgraded (about an hour ago), and I only see one Firefox
entry in the Add or Remove Programs panel (as opposed to 6 Thunderbird ones,
hehe -_-;;). So WFM...

Mozilla/5.0 (Windows; U; Windows NT 5.1; nl-NL; rv:1.7.7) Gecko/20050414
Firefox/1.0.3

~Grauw

    
    

    
  
(In reply to comment #149)
> This issue persists in version 1.0.3

Yes, as you clearly can see from the bugs status. Please read the bug before
making comments.

(In reply to comment #150)
> Strange, because I just upgraded (about an hour ago), and I only see one Firefox
> entry in the Add or Remove Programs panel (as opposed to 6 Thunderbird ones,
> hehe -_-;;). So WFM...

That is bug 247884, not this one.

    
    

    
  
*** Bug 290792 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 291094 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 291308 has been marked as a duplicate of this bug. ***

    
    

    
  
Suggestion: add "update" to description of bug. It seems from the number of dups
(one of which, despite having looked hard for the bug, is mine) that the
description isn't getting hit.
Summary: Installer options for where to put start menu / desktop / quick launch shortcut icons (empty folder created) → Installer options for shortcuts not obeyed (adds unwanted icons to desktop/quick launch/start menu after update)

    
    

    
  
Sorry for the spam, tweaking summary.
Summary: Installer options for shortcuts not obeyed (adds unwanted icons to desktop/quick launch/start menu after update) → Installer options for shortcuts don't work (update/install adds unwanted icons to desktop/quick launch, creates empty folder in start menu)

    
    

    
  
This is also vice versa. Setting the option to "not create icons on Desktop, in
Quick-Launch-Bar, and in Startmenu" are ignored. It is easyly reproducable:

1. create your own "config.ini". Set
[Windows Integration-Item0]
CheckBoxState=FALSE
Description=On my Desktop
Archive=

[Windows Integration-Item1]
CheckBoxState=TRUE 
Description=In my Start Menu Programs folder
Archive=

[Windows Integration-Item2]
CheckBoxState=FALSE
Description=In my Quick Launch bar
Archive=

This is expected to create a Startmenu item, but not on on the desktop and in
the quicklaunch bar. But all three are created - regardles of what is set in
"config.ini" if you give "-ms" to "setup.exe". The settings are respected,
clicking thru the setup wizard.

The same for "additional components". It doesn't matter what you set in
"config.ini" for some of them. It doesn't matter if "-ms" given to "setup.exe"
or not. Some are installed, some are not.

    
    

    
  
I see in comments that we're not going to get this fixed in 1.0.x due to the
policy for this branch, which is only about security fixes and such.  Which is
why 1.0.4 still has this issue.

However, I do so hope that it will be fixed in 1.1, which is pretty soon now.

I especially hope so because the installer for 1.1 is expected to go along with
this branch's new focus on easy upgrade.  I see a lot of comments here about
people still installing over existing FF directories, against explicit
instructions in the release notes.  Sometimes these people still see only one FF
entry in Add/Remove Programs, a luck I never had in the past.  So, for me,
whenever I upgrade a FF somewhere, I just backup its searchplugins directory,
remove it through the Control Panel, then erase its directory (which it seldom
does), reinstall fresh, and put the searchplugins directory back in.

This is a pain in the ass, and since 1.1 is supposed to handle upgrades
smoothly, I certainly would expect the installer to allow inplace upgrading, and
fix this icon issue.

As a matter of fact, if the upgrade remains in the same directory, it should
skip icon-related steps recorded as performed by the previous installation.

    
    

    
  
I totally agree.

    
    

    
  
Please don't mix the bugs.

This bug is about adding unwanted icons to desktop/quick launch, creates empty
folder in start menu.

This bug is not about adding firefox to windows software remove panel (this
problem is resolved in ff 1.0.3 as I know) and this bug isn't about "soft"
updates (which may come in ff 1.1 in around 3-4 weeks there will be an 1.1 alpha
release maybe it is integrated).

Also do not write any comments about your whiches, feelings and stupid "me too"s
this will only spam the mailbox of the developers with useless messages.

If you have whiches, search if another person postet a bug already and attach
you else open a new bug. Feelings are better in the forum of www.mozillazine.org
... "me too"s goes better in /dev/null.

    
    

    
  
1.0.4 installer still creates desktop shortcut regardless of whether I check or
un-check that option in the installer dialog.


    
    

    
  
*** Bug 293955 has been marked as a duplicate of this bug. ***

    
    

    
  
I can confirm Firefox 1.0.4 install, when asked to create no icons, creates at
least the empty program group, much to my annoyance.

    
    

    
  
Please do not post confirmation comments: This bug is not marked as FIXED, so
obviously it will still present this behavior.

    
    

    
  
It looks (to my untutored eye; forgive me if I'm mistaken), as though the patch
only works for "Custon" install.The default (standard) install option should be:
Don't install icons that the user doesn't request, i.e., the user's permission
should be  asked before cluttering up the desktop, start menu, etc. with
additional icons.

    
    

    
  
*** Bug 295133 has been marked as a duplicate of this bug. ***

    
  
Blocks: majorbugs

    
  
No longer blocks: majorbugs

    
    

    
  
*** Bug 295785 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 300209 has been marked as a duplicate of this bug. ***

    
    

    
  
The remaining issue here (empty folder in start menu if the user chooses to not
create those shortcuts) isn't really that severe, it's a minor annoyance, but
not something we can't ship one more release with.  (1.9 should bring a new
xulrunner-based installer)
Flags: blocking-aviary1.1? → blocking-aviary1.1-

    
    

    
  
(In reply to comment #169)

Reads like a Microsoft response to me! This bug has 57 duplicates. That alone
seems to me to be reason enough to fix it pronto.



    
  
Flags: blocking-aviary2.0?

    
    

    
  
(In reply to comment #170)
> Reads like a Microsoft response to me! This bug has 57 duplicates. That alone
> seems to me to be reason enough to fix it pronto.
> 

http://www.mozilla.org.uk/temp/etiquette.html



    
    

    
  
*** Bug 301016 has been marked as a duplicate of this bug. ***

    
    

    
  
I can verify that Firefox 1.0.5 installed on Windows XP, 

Process: 
Selected 'Custom Installation' when prompted
Unchecking the three boxes for 'start menu', 'quicklaunch' and 'desktop' when
prompted.

Promblems Experienced:
Checked "Launch Firefox Now", but firefox was not launched.
Unchecked "Install in Start Menu", but Start->Programs->"Mozilla Firefox" folder
was created and left empty.

    
    

    
  
*** Bug 301410 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 301800 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 301900 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 302600 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 302657 has been marked as a duplicate of this bug. ***

    
    

    
  
The installer for Deer Park Alpha 2 still behaves the same way.

(On Windows 98SE, ALL the icons are created regardless of user input.)
QA Contact: bugzilla → installer

    
    

    
  
Confirmed in Firefox 1.5 beta 1 under Windows XP. Unwanted desktop and menu
icons are created.

    
    

    
  
Is there a corresponding Thunderbird bug? Seeing there as well in recent 1.8
branch nightlies.

    
    

    
  
There seems to be some confusion about this bug. It is, in fact, fixed (for W2K
Pro and XP) if you accept the developers argument that a custom install is an
adequate solution. IMO, it's rude of applications to install shortcuts here
there and everywhere without asking permission, i.e., the default should be no
shortcuts and the customization should add them if desired.

    
    

    
  
(In reply to comment #182)
> There seems to be some confusion about this bug. It is, in fact, fixed (for W2K
> Pro and XP) if you accept the developers argument that a custom install is an
> adequate solution. IMO, it's rude of applications to install shortcuts here
> there and everywhere without asking permission, i.e., the default should be no
> shortcuts and the customization should add them if desired.

I think maybe I don't understand what you mean by `Custom install' (or what you
mean by fixed!), but, even if I clear the `Create a folder in the start menu'
(or whatever) check box, even in XP, even with 1.0.6, I still get a folder
appearing in my start menu.  (I don't get any desktop shortcuts, but then I
clear the checkboxes for them, too.)

    
    

    
  
Custom install, I believe, means that when you can choose between Typical or
Custom, you choose Custom.  I choose that every time to ensure that the Error
Agent is installed, and still I get this bug.  But, as they said, I didn't get
it for 1.0.6 on XP.

    
    

    
  
(In reply to comment #183)
> (In reply to comment #182)
> > There seems to be some confusion about this bug. It is, in fact, fixed (for W2K
> > Pro and XP) if you accept the developers argument that a custom install is an
> > adequate solution. IMO, it's rude of applications to install shortcuts here
> > there and everywhere without asking permission, i.e., the default should be no
> > shortcuts and the customization should add them if desired.
> 
> I think maybe I don't understand what you mean by `Custom install' (or what you
> mean by fixed!), but, even if I clear the `Create a folder in the start menu'
> (or whatever) check box, even in XP, even with 1.0.6, I still get a folder
> appearing in my start menu.  (I don't get any desktop shortcuts, but then I
> clear the checkboxes for them, too.)

(In reply to comment #183)
> (In reply to comment #182)
> > There seems to be some confusion about this bug. It is, in fact, fixed (for W2K
> > Pro and XP) if you accept the developers argument that a custom install is an
> > adequate solution. IMO, it's rude of applications to install shortcuts here
> > there and everywhere without asking permission, i.e., the default should be no
> > shortcuts and the customization should add them if desired.
> 
> I think maybe I don't understand what you mean by `Custom install' (or what you
> mean by fixed!), but, even if I clear the `Create a folder in the start menu'
> (or whatever) check box, even in XP, even with 1.0.6, I still get a folder
> appearing in my start menu.  (I don't get any desktop shortcuts, but then I
> clear the checkboxes for them, too.)

My apologies. You are correct. The Start menu glitch is still there in XP/1.0.6,
but the really annoying icons are gone (which should, IMO, be the default). 

    
    

    
  
> My apologies. You are correct. The Start menu glitch is still there in XP/1.0.6,
> but the really annoying icons are gone (which should, IMO, be the default). 

Meanwhile, on Windows 98 SE (and I'm guessing all Windows 9x), it's not just the
folder, but all the icons that get created regardless...

Either way, this should not be very hard to fix... many other programs have
options for installing or not installing icons, and I've never see this behavior
broken anywhere.

    
    

    
  
I just went through this by uninstalling my Sept. 8 FF1.5b1 build, and
installing this one: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050915 Firefox/1.4, "LastVersion=1.4_2005091504/1.8b4_2005091504"

I did a custom install, unchecked "Desktop Icon" and "Start Menu Group", leaving
"Quicklaunch" checked. I got the full deal, all three items were created. The
start menu folder wasn't empty, but two shortcuts for Firefox and Safe Mode are
in there. This isn't fixed, pretty darn sure.

    
    

    
  
I forgot to mention my OS: WinXP SP2 German. Just to rule out the Win9x/ME
speculations.

    
    

    
  
*** Bug 281296 has been marked as a duplicate of this bug. ***

    
    

    
  
Sigh, still happening in 1.0.7 custom install. Uncheck all shortcut options
still get a stupid empty folder. Tested on WinXP Pro and Home.

    
    

    
  
*** Bug 309811 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 309830 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 310000 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 310050 has been marked as a duplicate of this bug. ***

    
    

    
  
Same problem is reported for Firefox -  Bug 250744.

    
  
Flags: blocking1.8rc1?

    
    

    
  
*** Bug 250744 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 311959 has been marked as a duplicate of this bug. ***

    
    

    
  
We should get this right for 1.5. Who can help?
Flags: blocking1.8rc1?
Flags: blocking1.8rc1+
Flags: blocking-aviary2.0?

    
    

    
  
"Right," IMO, means both not installing shortcuts when they have been
deselected, band making this the default, i.e., not having to do a custom
install in order to turn off the shortcuts.

    
    

    
  
I can't reproduce this problem using the latest branch Windows installer build,
Windows XP. I get the expected results when selecting no icons, quick launch and
Desktop only, and Quick launch only.
No longer blocks: 256566

    
    

    
  
Since there weren't any checkins since the Beta2s, this comment should be valid.
Both Firefox and Thunderbird Beta 2 caused the problem for me *on my work
machine*. My home machine is alright. Both run WinXP SP2, German language. The
work machine is in a domain, does that impose different rights for the admin
account?

Just to make sure I just performed these steps: Uninstall Thunderbird. Clear
remnants in installation folder (updates, chrome, extensions? folders,
install.log file), left components/myspell dictionaries in place.

Ran thunderbird-1.4.1.en-US.win32.installer.exe for this tinderbox build:
[Compatibility]
LastVersion=1.4.1_2005101021/1.8b5_2005101021
LastPlatformDir=C:\Programme\Mozilla Thunderbird

- Custom install
- default folder
- unchecked talkback
- unchecked desktop icon, start menu shortcuts, left quickstart activated

Installer runs, creates desktop icon and start menu shortcuts. Bug is there.

BTW, is there a bug dealing with installing to the user's profile vs. the "All
users" profile? I wish MozApps would stay in my account, and don't clutter
everyones desktops and start menus.

    
    

    
  
Does this bug adress the issue in Firefox and Thunderbird.
https://bugzilla.mozilla.org/show_bug.cgi?id=250744
is marked as duplicate but adresses this in Thunderbird ...
Is this really a dup ???

    
    

    
  
(In reply to comment #202)
> Is this really a dup ???

Yes, bug 250744, comment 14 is very clear on this

    
    

    
  
*** Bug 312472 has been marked as a duplicate of this bug. ***

    
    

    
  
This bug's Product should be common one such as Core or Toolkit, since Bug
250744 has been close as DUP, which was reorted for Thunderbird.

    
    

    
  
I found the cause for this, it's a tricky bastard.
Assignee: dveditz → benjamin
Status: REOPENED → NEW

    
    

    
  


  
RegOpenKeyEx doesn't return ERROR_FILE_NOT_FOUND when the key is missing. This
fixes the behavior to use RegCreateKeyEx consistently (RegCreateKeyEx will
create a new key or return an existing key). This was hard to test because if
you already have run the installer once for this version, you won't see the
bug, only if you blow away the registry keys and start fresh.

        Attachment #199942 -
        Flags: review?(dveditz)

    
    

    
  
Comment on attachment 199942 [details] [diff] [review]
Use RegCreateKeyEx consistently

good catch on the missing CloseKey.
r=dveditz

        Attachment #199942 -
        Flags: review?(dveditz) → review+

    
  

        Attachment #199942 -
        Flags: approval1.8rc1?

    
    

    
  
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 20 years ago → 19 years ago
Resolution: --- → FIXED

    
  
Flags: blocking-aviary2.0-

    
  
Flags: blocking-aviary2.0-
Flags: blocking-aviary1.5-

    
    

    
  
Comment on attachment 199942 [details] [diff] [review]
Use RegCreateKeyEx consistently

I'm going to prematurely approve this for the branch even though we haven't
gotten a trunk verification on it yet since the change is isolated to the
installer.

        Attachment #199942 -
        Flags: approval1.8rc1? → approval1.8rc1+

    
    

    
  
Fixed on 1.8 branch.
Keywords: fixed1.8

    
    

    
  
On the Burning Edge (http://www.squarefree.com/burningedge/releases/1.5rc1.html) it says that this bugfix has made its way into Fx 1.5 RC1. Unfortunately I have just installed this version of Firefox, and one of the problems addressed in this report still persists on Windows ME:

The Firefox installer (custom install) ignores your choices for icon placement: it puts icons on the desktop, Quick Launch and Start Menu even if you ask it not to.

This bug also persists in the latest nightly build (1.6a1, downloaded on 2 Nov 05).


    
    

    
  
*** Bug 314762 has been marked as a duplicate of this bug. ***

    
    

    
  
Anton, this behaves correctly for me on current trunk and branch nightlies; can you attach a regmon log (http://www.systinternals.com/) of running the installer?

    
    

    
  

      
      
      
      

        Attached file
          
        Regmon log file
        — 
      

    


  
Hi,

RegMon details attached, corresponding to installation of Fx 1.5rc1 on WinMe. Let me know if you need more info. Cheers.

    
    

    
  

      
      
      
      

        Attached file
          
        Regmon log file
        — 
      

    


  
Hi,

RegMon details attached, corresponding to installation of Fx 1.5rc1 on WinMe. Let me know if you need more info. Cheers.

    
    

    
  
Seems like the registry entries indicating whether to create the shortcuts aren't being created, and the shortcut creation code only checks != 0. Changing the check to == 1 would fix it, I'd think.

    
    

    
  
To be clearer, seems like getValueNumber returns UNEXPECTED_ERROR (-201) for if the registry key doesn't exist, so since -201 != 0, the shortcuts are created.

http://lxr.mozilla.org/seamonkey/source/xpinstall/src/nsWinReg.cpp#803

http://lxr.mozilla.org/seamonkey/source/browser/installer/windows/ab-CD.jst#156

The question is why the registry keys aren't being created... maybe a permissions issue?

    
    

    
  
I just wanted to point out that there were precisely two lines that were added to my RegMon log (see my attachment above) at the point of the installation where I choose my icons. They are:

95.22479600	Setup:FFFA6315	OpenKey	HKCU\SOFTWARE\\Mozilla\\Mozilla Firefox\\1.5 (en-US)\\Main	BADKEY		
95.22480400	Setup:FFFA6315	CreateKey	HKCU\SOFTWARE\\Mozilla\\Mozilla Firefox\\1.5 (en-US)\\Main	BADKEY		

They are both flagged as BADKEY, which seems to stem from the fact that the paths involve "\\" instead of just "\" (which appears to be incorrect). Could this be the cause of the problem?

FYI, there are just a handful of other lines in the whole of the log which are BADKEYS: Line numbers 830, 831 and 833, and then line numbers 17279--17283. These latter lines are:

125.77074400	Setup:FFFA6315	OpenKey	HKLM\Software\mozilla.org\GRE\\Main	BADKEY		
125.77130400	Setup:FFFA6315	OpenKey	HKLM\Software\mozilla.org\GRE\\Main	BADKEY		
125.77184160	Setup:FFFA6315	OpenKey	HKLM\Software\mozilla.org\GRE\\Main	BADKEY		
125.77239040	Setup:FFFA6315	OpenKey	HKLM\Software\mozilla.org\GRE\\Main	BADKEY		
125.77293440	Setup:FFFA6315	OpenKey	HKLM\Software\mozilla.org\GRE\\Main	BADKEY		

Note the "\\" which seems to ruin this path. (I wonder if these bad lines cause some other problem with the installation process?)


    
    

    
  
(In reply to comment #219)
Anton, which version of Windows are you running? Are you a limited user, or do you have any other restricted permissions? I tried a clean install and the creation of the reg keys worked for me. Does the same problem appear with both branch and trunk installers? Can you compare logs from the two?

    
    

    
  
Oops, I should read more closely, I see you're using the RC1 installer on Windows ME.

    
    

    
  
*** Bug 314869 has been marked as a duplicate of this bug. ***

    
    

    
  
I am running WinME. Although my system is quite heavily customized, there's nothing on it which would interfere with its current user accounts setup, which is the default for Win9x---no user accounts created, anyone using the machine is granted full permissions.

I have done the install again using yesterday's nightly build ("Deer Park Alpha 2 1.6a1"). Exactly the same problem: after I chose which icons I wanted and clicked "Next", RegMon recorded the same two malformed registry keys as above: the pathname contains "\\" instead of "\".

(Incidentally, the same five other BADKEYS I mentioned above also occured again. (They occurred immediately after I unchecked "Launch" and clicked "Finish". Although this has nothing to do with this problem because the icons had already been created prior to this point, it might signal another problem elsewhere.)


    
    

    
  
(In reply to comment #223)
> I am running WinME. Although my system is quite heavily customized, there's
> nothing on it which would interfere with its current user accounts setup, which
> is the default for Win9x---no user accounts created, anyone using the machine
> is granted full permissions.
> 
> I have done the install again using yesterday's nightly build ("Deer Park Alpha
> 2 1.6a1"). Exactly the same problem: after I chose which icons I wanted and
> clicked "Next", RegMon recorded the same two malformed registry keys as above:
> the pathname contains "\\" instead of "\".
> 
> (Incidentally, the same five other BADKEYS I mentioned above also occured
> again. (They occurred immediately after I unchecked "Launch" and clicked
> "Finish". Although this has nothing to do with this problem because the icons
> had already been created prior to this point, it might signal another problem
> elsewhere.)
> 


Anton,

"\\" would be correct in a path using backslashes since backslashes are a special character in most operating systems and programming languages that escapes (or flips whether the next character is treated literally or specially).  So in order for it to be treated like a normal "\" it has to be escaped itself as a literal, so "\\".  Although, I don't know that it would be showing up in the path itself if it were being used for escaping, normally only one backslash shows up (the second one) and the escape character is dropped in the output.  It is possible that is breaking it though, since "\\" in Windows is the first part of a path when you are going to a NetBIOS server.

    
    

    
  
> "\\" would be correct in a path using backslashes

Indeed. However the path I am talking about is not a file path (in which case your statement applies) but a Registry Key path in the RegMon log. In other words, it's the call to the registry key that is malformed and hence fails.

> Although, I don't know that it would be showing up in the path itself
> if it were being used for escaping

Precisely.

The point, surely, is that none of the other ~63000 RegMon log lines involving reg key paths show "\\" ! And none of them are logged as BADKEY. Yet the seven which do *are* logged as BADKEY. And the creation of icons just so happens to correspond to two of those seven lines. I would suggest that this is not a coincidence.

    
    

    
  
Ben/Gav, Bug 312472 wrongly marked dupe by Adam G. Did anyone bother reading that descript?

But aside, do you guys think that plays a role in this bug directly or indirectly? As in when that broke this broke, assuming the custom directory in relation to the proper shortcut for it error has been around for an equal amount of time to this one. Cause I'm sensing a dependency even though the workings of the errors should be dealing with different aspects of the Installer...


    
    

    
  
(In reply to comment #220)
> (In reply to comment #219)
> Anton, which version of Windows are you running? [...] I tried a clean install
> and the creation of the reg keys worked for me.

Gavin, which version of Windows are /you/ running on? If you managed to get it to work on Windows ME, could you also post your regmon log to compare with mine?

Thanks,
Anton


    
    

    
  
The symptoms of this bug on Windows 9x platforms have not been quite the same as on Windows 2000/XP. What happens on Windows 9x is that ALL the icons are created regardless of user input (so for example no such thing as an empty Start Menu folder, which was one of the possible scenarios for Windows 2000/XP). So this bug might actually be two bugs, seeing as the resolution that was posted did not fix things for Windows 98.

    
    

    
  
Again, this bug is not fixed for Windows 9x systems. Is it better to file a new bug specific to Window 98 (there are some that were previously filed, but marked as duplicates of this one, perhaps incorrectly).

    
    

    
  
The installer that comes with the recently released Bon Echo Alpha 3 fixes the problem on Windows 98.

That's good news.

I guess it also means that the issue will not be fixed for Firefox 1.5.* and Windows 9x.

    
    

    
  
(In reply to comment #230)
> I guess it also means that the issue will not be fixed for Firefox 1.5.* and
> Windows 9x.
There are no plans to backport this for 1.5.x. The new installer will be available with the 2.0 release.



    
    

    
  
A friend emailed me a report that part of this bug still exists in XP (a virtual installation, if that matters), with the latest fresh download (2.0.0.1):

* Create new WinXP system (Virtual, in Parallels.)
* Launch IE
* <http://www.getfirefox.com>
* Download & install
   - On the page that says "Create icons on..." *UN-*check "on my desktop"
   - Finish installation

EXPECTED: No icon on my desktop
ACTUAL: icon on my desktop

    
    

    
  
Pam, could you file a new bug for that issue?

    
    

    
  
Disquised as plugins for Mozilla Firefox, had to delete MF completely. I was always updating MF regularly too. But Trend Micro PC consistently gave WARNINGS of these problems. Hope awareness is known? Since all problems are deleted not to able to list them. Did see about 10 virus/spyware linked with Mozilla plugins.

    
    

    
  
Disquised as plugins for Mozilla Firefox, had to delete MF completely. I was always updating MF regularly too. But Trend Micro PC consistently gave WARNINGS of these problems. Hope awareness is known? Since all problems are deleted not to able to list them. Did see about 10 virus/spyware linked with Mozilla plugins.

    
    

    
  
(In reply to alanjstr from comment #22)
> (In reply to comment #21)
> > I also think that no shortcuts should be installed by default if it's an 
> > update/upgrade, because the shortcuts should already be in place and otherwise 
> > the user has to adjust the options every time he updates/upgrades.
> 
> Offering to install the shortcuts by default seems to be industry standard.

kbjkbkbk

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: