1789991 - Two Firefox Private icons are displayed on All Programs menu.

Status: VERIFIED FIXED

(Firefox :: Private Browsing, defect, P1)

Description

[Monica Chiorean]

Attachment: Screenshot1.jpg

Note
*Issue reproduces only on Win7

Found in

• 106.0a1(20220908213354)

Affected versions

• 106.0a1(20220908213354)

Tested platforms

• Affected platforms:Win7
• Unaffected platforms: Win10, Ubuntu, Mac

Steps to reproduce

1. Uninstall all existing Firefox builds, delete all profiles and registry.
2. Do a Nightly clean install with the latest build.
3. Check all Firefox icons from Start - All Programs menu.

Expected result

• Only one Private icon for Firefox should be displayed.

Actual result

• There are two Private icons for Firefox on All programs.

Regression range

• First bad build: we saw the issue starting with build 106.0a1(20220908213354)

Additional notes

• Issue also reproducing for localizations (French-confirmed) and only on Win7.

Comment 1

[[e-mail] (:bhearsum)]

This looks like private shortcuts for two different versions of Firefox. Can you take a look at the details of each, and see which installs they point to? ("Nightly Private Browsing" sounds like an unofficial build, while "Firefox Nightly Private Browsing" is a proper Nightly.)

Comment 2

[Monica Chiorean]

Attachment: Record.gif

Comment 3

[Monica Chiorean]

Attachment: 2022-09-09_13h25_48.png

I attached a record of the actions I did at clean install and a screenshot of the folders, please let me know if more details are needed. Thank you.

Comment 4

[[e-mail] (:bhearsum)]

It looks like this is due to a mismatch in what "brand short name" means in the Nightly branding. In the installer, it is "Firefox Nightly" (via MOZ_APP_DISPLAYNAME), while in the browser, it is simply "Nightly". Other brandings appear to be consistent.

This inconsistency seems to date back to https://bugzilla.mozilla.org/show_bug.cgi?id=1378834, where we wanted to start using "Firefox Nightly" in shortcuts instead of just "Nightly".

I think the best will end up being creating a new in-product string for shortcut text brands - since none of the existing ones (-brand-shorter-name, -brand-short-name, -brand-full-name) are consistent across all brandings.

Comment 5

[[e-mail] (:bhearsum)]

Attachment: Bug 1789991: use a distinct string for in-product shortcut names r?nalexander!

In days of old, it was safe to use -brand-short-name for this, as it always lined up with the installer's concept of BrandShortName. This changed when https://bugzilla.mozilla.org/show_bug.cgi?id=1378834 landed -- which started using "Firefox Nightly" for the nightly branding BrandShortName in the installer (but maintained "Nightly" as the in-product -brand-short-name). Changing one or the other of these is not really a viable option:

• Changing the installer's BrandShortName for Nightly to match -brand-short-name would cause shortcuts to simply be called "Nightly" -- which is the opposite of what the aforementioned bug wanted
• Changing -brand-short-name would cause a number of in-product strings to start using "Firefox Nightly" instead of "Nightly" -- which is probably undesirable for a few reasons, not the least of which is possible l10n implications

For these reasons, and the relatively short timeline I have to fix this, I'm taking the simplest and easiest path of introducing a new string specifically for in-product shortcut names, which lines up with the installer's values for BrandShortName. (We perhaps should also separate this out in the installer -- but it's unnecessary here, so I did not go to the trouble.)

Comment 6

[[e-mail] (:bhearsum)]

Attachment: Bug 1789991: correctly detect existing private browsing shortcuts r?bytesized!

This was an oversight during the original implementation in bug 1761291. I updated the code that creates shortcuts there, but not the code that looks at existing ones.

Depends on D156991

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/c31659a11f1f
use a distinct string for in-product shortcut names r=nalexander,flod

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/81bc1cdc3645
correctly detect existing private browsing shortcuts r=bytesized

Comment 9

[Cristina Cozmuta (:CrissCozmuta)]

https://hg.mozilla.org/mozilla-central/rev/c31659a11f1f
https://hg.mozilla.org/mozilla-central/rev/81bc1cdc3645

Comment 10

[Monica Chiorean]

I verified the fix on Win7 using Nightly build 106.0a1 (20220913213020) and the issue is fixed on en-US build, but still broken for fr (French / Spanish localizations), should I reopen this issue for French/Spanish?

Comment 11

[Monica Chiorean]

Attachment: build 106.0a1

Comment 12

[[e-mail] (:bhearsum)]

(In reply to Monica Chiorean from comment #10)

I verified the fix on Win7 using Nightly build 106.0a1 (20220913213020) and the issue is fixed on en-US build, but still broken for fr (French / Spanish localizations), should I reopen this issue for French/Spanish?

The image attached has an en-US and French shortcut. It looks like you may have done the French install without first removing the en-US shortcut? I wasn't able to reproduce in a clean environment with just the French build.

Comment 13

[[e-mail] (:bhearsum)]

(In reply to [e-mail] (:bhearsum) from comment #12)

(In reply to Monica Chiorean from comment #10)

I verified the fix on Win7 using Nightly build 106.0a1 (20220913213020) and the issue is fixed on en-US build, but still broken for fr (French / Spanish localizations), should I reopen this issue for French/Spanish?

The image attached has an en-US and French shortcut. It looks like you may have done the French install without first removing the en-US shortcut? I wasn't able to reproduce in a clean environment with just the French build.

Monica and I spoke on Slack. This is indeed a real, but separate, issue. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1790809 for it.

Comment 14

[Monica Chiorean]

Could not reproduce the issue using latest Nightly build 106.0a1(20220916033628). The remaining issue is bug 1791161.