266340 - Unnecessary icon creation with Firefox update

Status: RESOLVED WONTFIX

(Toolkit :: Application Update, defect)

Description

[Doug Wright]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041026 Firefox/1.0RC1

When I install Firefox from the normal installer, I choose not to have a desktop
icon created.

After installing via the update system, I found an unwanted, unasked for Firefox
icon on my desktop.

I assume that the update would also have created quicklaunch and start menu
items if I didn't have them already.

Simply disabling icon creation for the update-installer seems appropriate -
wanted icons will already exist from the initial install.

Reproducible: Didn't try
Steps to Reproduce:

Comment 1

[Bill Mason]

Could be a dup of bug 245392.

Comment 2

[Doug Wright]

It's not a dupe - 245392 deals with creating a start menu folder even when the
user chooses no start menu icon (which is respected).

This is about having actual icons created.

Comment 3

[Steuard Jensen]

I see the same effect after running the update to RC1 on Win 98 (even though
that update failed).  I agree with the original reporter: update should never
need to add or remove shortcuts, since the user presumably set them as desired
during installation.  (For the record, I went ahead and tried to reproduce the
effect despite breaking my browser each time; it happened both times.)

Comment 4

[Michael Lefevre]

not sure if this is a bug or an enhancement request (to have the option of not
adding an icon), but confirming.

Comment 5

[Doug Wright]

(In reply to comment #4)
> not sure if this is a bug or an enhancement request (to have the option of not
> adding an icon), but confirming.

Why would in-place application update ever need to create new icons? Thanks for
confirming anyway.

Comment 6

[sfmag]

this happens across the board, regardless of update/installation method.
on XP as an admin, it creates a set for you and creates another for All Users,
even if neither are asked for.

Comment 7

[Asa Dotzler [:asa]]

ben's gonna look.

Comment 8

[David Bruhn]

This happened to me with Thudnerbird too... related?

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

To do this right and test it properly would take more time than we have, I've
decided after some investigation. Not a blocker. 

Comment 10

[djpohly]

Could Bug 267851 be related via "overall iconic sloppiness during updates?"

Also happens in trunk builds (hacked to update from tinderbox) -- consistently
reproducible.

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

Comment 11

[Worcester12345]

(In reply to comment #10)
...
> Also happens in trunk builds (hacked to update from tinderbox) -- consistently
> reproducible.
...
"Aviary landing"?

Comment 12

[Asa Dotzler [:asa]]

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

Comment 13

[Chris]

WFM

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

Comment 14

[Steuard Jensen]

I don't know whether this was actually fixed for everyone as of comment #13, but my impression is that this bug has become irrelevant with the new binary patching update system in Firefox 1.5.  Does this bug's "1.0 branch" version label mean that it will stay open until 1.0 is no longer supported, or should it be resolved WORKSFORME or WONTFIX?

Comment 15

[Nick Thomas [:nthomas] (UTC+12)]

As comment #14 notes, this bug was superseded by the improved updater, and 1.0.x is now unsupported. --> WONTFIX