1819549 - Firefox Private mode shortcut still added to Start menu when unchecked in installer

Status: RESOLVED DUPLICATE of bug 1814792

(Firefox :: Installer, defect)

Description

[maik.diessner]

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0

Steps to reproduce:

1. Install Firefox 110.0.1 (64-bit) on Windows 8.1 with "add to Start menu" option unchecked

Actual results:

Firefox Private mode entry added to Start menu

Bug was introduced some versions ago where private mode got some rehaul.

Expected results:

No Start menu entries gettig created

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Nick Alexander :nalexander [he/him]]

Marking this as high priority until investigated. Thanks for the report, OP!

Comment 3

[Robin Steuber (she/her) [:bytesized]]

Ugh, I thought I would just quickly fix this but, to my surprise, there isn't really a quick fix to be had here. Let me explain the issue.

In theory, we can make this change quite easily by moving this NSIS code into the above block. But even if we do that, the shortcut will end up being created when Firefox launches, here. This code exists to ensure that the start menu icon exists even if the installation was not created with the installer.

The comment on the NSIS code partially explains why we do this. There are several bits of Windows functionality that inexplicably fail or don't work as expected if there is not a start menu shortcut with a matching AUMID. One of these is pinning to the taskbar. If Firefox tries to pin a Private Browsing icon to the taskbar without that shortcut existing, it won't pin properly. Potentially we could fix this by only adding the start menu shortcut at that time, which wouldn't really respect what the user wants, but if the user does want the taskbar pin, we'd be doing about the best that we can.

But there is a bigger issue. The Windows UI (right clicking the private browsing icon and clicking "Pin to taskbar") also stops working properly if this shortcut doesn't exist. The thing is that, even though we provide private_browsing.exe, all it really does is invoke firefox.exe -private-window. The private window uses a different AUMID so it gets a different icon and doesn't group in the taskbar with Firefox. But it's still a Firefox process. When Windows goes to pin it and the shortcut exists, it is able to connect the AUMID to the one in the shortcut and thus knows to correctly pin private_browsing.exe (since that is the target of the shortcut). But if the shortcut doesn't exist, Windows doesn't know about private_browsing.exe and simply pins firefox.exe (without the -private-window switch). Then, when it is clicked, it doesn't actually open a Private Browsing window; it just opens Firefox.

I don't want to close this bug because, ideally, I would really like for us to fix this. But, as things are, I don't see any way to fix this without breaking Windows' ability to pin a Private Browsing window to the taskbar.

Comment 4

[Robin Steuber (she/her) [:bytesized]]

ni? nishel per discussion in team meeting today.

Comment 5

[elvisrowe]

Just a random thought from a user. Instead of creating/verifying the icon during application launch, why not create/verify the existence of the icon when Private Browsing is first initiated? To me this would make it seem an additional "feature" was activated when I launched Private Browsing mode. Unfortunately, it doesn't solve the underlying issue, but I know in my usage case I would rather this alternative versus what is currently happening.

Comment 6

[Nick Rishel [:nrishel]]

:bytesized I suspect there's a way to simplify logic for when we manually pin to the taskbar to not rely on a start menu shortcut, but I think you and Ben are right that there's not much we can do about the taskbar right click menu pin. Maybe creating an AUMID in the registry's HKLM\Software\Classes\AppUserModelId like we use for notifications and some other changes could be made to work, but I didn't see a promising path after a quick browse browser of the registry.

Comment 7

[Rares Doghi, Desktop QA]

Could this issue be a Dupe of Bug 1814792 ?

Comment 8

[Nick Alexander :nalexander [he/him]]

(In reply to Rares Doghi, Desktop QA from comment #7)

Could this issue be a Dupe of Bug 1814792 ?

Yes, I think it is.