Closed Bug 312472 Opened 14 years ago Closed 13 years ago

Start menu shortcuts point to wrong directory after installing in custom directory

Categories

(Firefox :: Installer, defect, minor)

x86
Windows XP
defect
Not set
minor

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: bugzilla.mozilla.org, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

When choosing to install Firefox in a custom folder instead of the default, the
shortcuts that are created in the Start menu point to a wrong (nonexistent)
location.
Example: default installation directory is C:\Program Files\Mozilla Firefox,
custom folder is E:\Apps\Firefox, then the shortcuts point to E:\Apps\Mozilla
Firefox !

Reproducible: Always

Steps to Reproduce:
1. Choose to install the application in a custom folder
2. Create the folder using the installer
3. Run the installer
4. Try to run Firefox from the shortcut in the Start menu after installation
completes

Actual Results:  
Windows says "Missing shortcut" and starts searching for the application.

Expected Results:  
Start Firefox.

I tried to clean up all information about any previous installations I could
find, to start the install as clean as possible.

*** This bug has been marked as a duplicate of 245392 ***
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
(In reply to comment #1)
> 
> *** This bug has been marked as a duplicate of 245392 ***

This does *NOT* seem to be the same bug! 245392 seems to be about icons being
created when they are not requested.
My bug is about icons being created pointing to the wrong directory!

If this is a duplicate, can someone show me in what way?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Yeah, I agree with you, Peter. Appears someone has completely written you off. I'm going to bring this up to Gavin's attention in the event I can actually contact him. He's been so busy lately but I don't know if more than Boris. Those guys are working their asses off [& the ones currently addressing this bug, which why I bring them up]. 

I should know, their names are practically plastered up everywhere. As I've been following tons of bug commentary, in a game of catch up, for the past couple months I was out of updating & familiarizing myself with FF development. It had to be done. I'm pretty much glad I didn't cave and try any nightlies since my oath not to use them since Feb of this year. I just knew too many nasty bugs/regressions were going to come out of it. Call it a gut feeling. I would've absolutely gone nuts with the recent infinite update loop or the Firefox in-place update build killer, not to mention whatever else that has manifested in that time off. Other than the FF version lingo beginning to wildly be a nuisance for me.

But I think this is another contribution to what may be a factor/co-factor in what's wrong with the Installer icons disobeying user preference fiasco. Or, just some extra dirty tidbit that we found after we opened a pipe for a quick rinse and fix. In either case I don't see this as warranting a dupe; that's premature. If anything I'd say they had a dependency on each other.
I've tested this with the new installer that landed - bug 326580 - and it is wfm.
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago13 years ago
Resolution: --- → WORKSFORME
(In reply to comment #4)
> I've tested this with the new installer that landed - bug 326580 - and it is
> wfm.
> 

Is this 1.8 and trunk only? Because version is "unspecified", unless that is the designation when there is 2 out of 3?
You need to log in before you can comment on or make changes to this bug.