Two Firefox Private icons are displayed on All Programs menu.
Categories
(Firefox :: Private Browsing, defect, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox106 | --- | verified |
People
(Reporter: mchiorean, Assigned: bhearsum)
References
(Depends on 1 open bug)
Details
(Whiteboard: [fidedi-pbm])
Attachments
(6 files)
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
- Uninstall all existing Firefox builds, delete all profiles and registry.
- Do a Nightly clean install with the latest build.
- 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.
Reporter | ||
Updated•2 years ago
|
Assignee | ||
Comment 1•2 years ago
|
||
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.)
Reporter | ||
Comment 2•2 years ago
|
||
Reporter | ||
Comment 3•2 years ago
|
||
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 | ||
Updated•2 years ago
|
Assignee | ||
Comment 4•2 years ago
|
||
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.
Assignee | ||
Updated•2 years ago
|
Updated•2 years ago
|
Assignee | ||
Comment 5•2 years ago
|
||
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.)
Assignee | ||
Comment 6•2 years ago
|
||
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 9•2 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c31659a11f1f
https://hg.mozilla.org/mozilla-central/rev/81bc1cdc3645
Reporter | ||
Comment 10•2 years ago
|
||
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?
Reporter | ||
Comment 11•2 years ago
|
||
Assignee | ||
Comment 12•2 years ago
|
||
(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.
Assignee | ||
Comment 13•2 years ago
|
||
(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.
Reporter | ||
Comment 14•2 years ago
|
||
Could not reproduce the issue using latest Nightly build 106.0a1(20220916033628). The remaining issue is bug 1791161.
Description
•