Closed Bug 1789991 Opened 2 years ago Closed 2 years ago

Two Firefox Private icons are displayed on All Programs menu.

Categories

(Firefox :: Private Browsing, defect, P1)

Firefox 106
Desktop
Windows 7
defect

Tracking

()

VERIFIED FIXED
106 Branch
Tracking Status
firefox106 --- verified

People

(Reporter: mchiorean, Assigned: bhearsum)

References

(Depends on 1 open bug)

Details

(Whiteboard: [fidedi-pbm])

Attachments

(6 files)

Attached image 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.
Severity: -- → S2
Has STR: --- → yes

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.)

Flags: needinfo?(monica.chiorean)
Attached image Record.gif
Flags: needinfo?(monica.chiorean)
Attached image 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.

Assignee: nobody → 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.

Priority: -- → P1
Whiteboard: [fidedi-pbm]

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.)

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

Pushed by bhearsum@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c31659a11f1f
use a distinct string for in-product shortcut names r=nalexander,flod
Pushed by bhearsum@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/81bc1cdc3645
correctly detect existing private browsing shortcuts r=bytesized
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 106 Branch

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?

Flags: needinfo?(bhearsum)
Attached image build 106.0a1

(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.

Flags: needinfo?(bhearsum) → needinfo?(monica.chiorean)

(In reply to bhearsum@mozilla.com (: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.

Flags: needinfo?(monica.chiorean)

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

Status: RESOLVED → VERIFIED
Depends on: 1750758
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: