2063459 - Firefox keeps creating a Start Menu shortcut every time it opens, overwriting custom locations and other release channels

Status: NEW

(Firefox :: Shell Integration, defect)

Description

[Gabe Pérez]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:154.0) Gecko/20100101 Firefox/154.0

Steps to reproduce:

Every time I launch Firefox Developer Edition (whether it's a normal window or a private one), it automatically creates a new shortcut in the Windows Start Menu folder.

Steps to reproduce:

1. Open Firefox Developer Edition.
2. Check the user's Start Menu folder located at: C:\Users\[username]\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
3. Close and open the browser again.

Actual results:

Firefox creates a shortcut in that folder on every single launch. This is especially frustrating when using the Portable version, because it leaves junk shortcuts behind on every PC I use it on.

My Workaround:

On my personal laptop, I found a way to stop this. I deleted the duplicate shortcut in the AppData folder, and then went to the original shortcut created during installation (located in C:\ProgramData\Microsoft\Windows\Start Menu\Programs). I changed the properties of that original shortcut to Read-only. By doing this, Firefox is blocked from generating the duplicate shortcut.

Note: I've only seen this behavior starting in v154. I remember in version 153 there was a similar issue where Firefox would add itself to the Windows auto-startup list. That got fixed, but I figure this new shortcut issue might be related to whatever caused the previous bug.

Expected results:

The browser shouldn't create new shortcuts every time it runs.

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Win32' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Harshit Sohaney [:hsohaney]]

Is it creating a new shortcut everytime? In the end, is there just the 1 shortcut, or are there multiple?

I think this is related to this change Bug 2056382.

Comment 3

[Gabe Pérez]

(In reply to Harshit Sohaney [:hsohaney] from comment #2)

Is it creating a new shortcut everytime? In the end, is there just the 1 shortcut, or are there multiple?

I think this is related to this change Bug 2056382.

Firefox automatically creates a shortcut only once; it doesn't duplicate or repeat it, unless it cannot find an existing shortcut or if the shortcut lacks read protection.

I hope I'm explaining this clearly: If Firefox doesn't find a shortcut in the home directory, it creates one (both for the normal window and the private window, right when I open a private window). If Firefox does find a shortcut, it doesn't create a new one; however, it does modify the target location (though if I set the attribute to read-only, it won't modify it either).

Comment 4

[Gabe Pérez]

(In reply to Harshit Sohaney [:hsohaney] from comment #2)

Is it creating a new shortcut everytime? In the end, is there just the 1 shortcut, or are there multiple?

I think this is related to this change Bug 2056382.

The issue still persists in the new Firefox Nightly 156, even after setting browser.shell.customIcon.enabled to false.

Comment 5

[John T. Haller (email is bugzilla2@)]

This issue made it into Firefox 154.0 stable for Windows. It's now breaking existing Firefox shortcuts for users that use multiple copies/versions/channels of Firefox. And it breaks the local shortcut if a user uses Firefox Portable, leaving the computer unable to launch Firefox from the start menu.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=2064652#c11

Comment 6

[Gabe Pérez]

(In reply to John T. Haller (email is bugzilla2@) from comment #5)

This issue made it into Firefox 154.0 stable for Windows. It's now breaking existing Firefox shortcuts for users that use multiple copies/versions/channels of Firefox. And it breaks the local shortcut if a user uses Firefox Portable, leaving the computer unable to launch Firefox from the start menu.

See: https://bugzilla.mozilla.org/show_bug.cgi?id=2064652#c11

It doesn't leave Firefox totally unusable, but duplicate shortcuts are created if you customize the original shortcut location after install.

​I spotted this on Firefox Developer Edition—my main setup across my laptop and flash drive. It's particularly annoying when running Firefox Portable on third-party PCs, as it leaves unwanted shortcuts behind.

Comment 7

[John T. Haller (email is bugzilla2@)]

(In reply to Gabe Pérez from comment #6)

It doesn't leave Firefox totally unusable, but duplicate shortcuts are created if you customize the original shortcut location after install.

​I spotted this on Firefox Developer Edition—my main setup across my laptop and flash drive. It's particularly annoying when running Firefox Portable on third-party PCs, as it leaves unwanted shortcuts behind.

If I run Firefox Portable on my machine, it takes over the existing Firefox shortcut to the local version. It doesn't create a second one, it takes over the existing one as detailed in the linked bug. When I remove the drive Firefox Portable is on, the Firefox shortcut on the local PC no longer works.

Comment 8

[John T. Haller (email is bugzilla2@)]

Also noticed that if I have an icon called Firefox Developer Edition (Local) within %APPDATA%\Microsoft\Windows\Start Menu\Programs, Firefox Developer Edition doesn't create its icon and then runs with a broken taskbar icon.

Comment 9

[Alice0775 White]

I can also reproduce the issue on Nightly156.0a1 Windows11.

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=137da4e271e87fb128457ab2569fcdbe568bfd36&tochange=5a12167c19e6ac930be01df504b98a7da764ee60

Comment 10

[BugBot [:suhaib / :marco]]

:yazan, since you are the author of the regressor, bug 2056382, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 11

[maik.diessner]

Attachment: Screenshot.png

Comment 12

[maik.diessner]

Attachment: Video.mp4

Comment 13

[maik.diessner]

Confirmed here too. Version 153 and previous versions did not show this behaviour.