Found in

• Firefox 106.0b4

Affected versions

• Firefox 106.0b4
• Firefox 107.0a1

Tested platforms

• Affected platforms: Win 7, Win 10, Win 11
• Unaffected platforms: macOS, Ubuntu

Steps to reproduce

1. Install Firefox and open the installation folder.
2. Scroll down to the Private Window icon and pin it to the Taskbar/Start Menu.
3. Hover the icon. (or observe the title)

Expected result

• The title is “Firefox Private Browsing”.

Actual result

• The title is “private_browsing”.

Regression range

• If there is one I will try to find it as soon as possible.

Additional notes

• If there are multiple pins to the Start Menu, then multiple “private_browsing(2)” icons are displayed on the Start Menu.
• This issue affects locale builds as well.

This ought to be fairly easily fixable. The private_browsing.exe binary doesn't have a proper "Description" set, which is causing this.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #1)

This ought to be fairly easily fixable. The private_browsing.exe binary doesn't have a proper "Description" set, which is causing this.

I spoke too soon, of course. To fix this we're going to need to add a module.ver for the Private Browsing wrapper. That part is easy enough -- but the strings we use for Private Browsing titles and shortcuts are localized -- and it's not clear to me whether or not we can localize the strings in these files.

Worst case scenario we can probably just use a non-localized string here (probably MOZ_APP_DISPLAYNAME), but we should at least try to do better...

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #2)

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #1)

This ought to be fairly easily fixable. The private_browsing.exe binary doesn't have a proper "Description" set, which is causing this.

I spoke too soon, of course. To fix this we're going to need to add a module.ver for the Private Browsing wrapper. That part is easy enough -- but the strings we use for Private Browsing titles and shortcuts are localized -- and it's not clear to me whether or not we can localize the strings in these files.

Worst case scenario we can probably just use a non-localized string here (probably MOZ_APP_DISPLAYNAME), but we should at least try to do better...

I checked with the l10n team and we have no existing way to localize strings for these files. Given that, I think we ought to add a non-localized string for now, and file a follow-up to localize it....someday.

This is, I think, an improvement to the hover text when a user directly pins private_browsing.exe to the Taskbar through Explorer. When pinned like this, we have no control over the text of the shortcut. Windows uses the EXE Description -- so we end up with private_browsing.lnk, which causes private_browsing as the hover text.

With this patch, it ends up being MOZ_APP_DISPLAYNAME, which in the real world will typically come out as something like "Firefox Nightly" or "Firefox Nightly (2)" (the latter will happen if a "Firefox Nightly" shortcut already exists). I think this is an improvement over the current situation, as it least it's a more human readable string, and different per branding - but I'm open to opinions here.

In an ideal world this would be a localized string, but due to it ultimately coming from configure.sh, we do not have an existing method to localize it.

Even if we want to use a different string here we ought to take some form of this patch so that we get exe metadata for private_browsing.exe.

https://hg.mozilla.org/mozilla-central/rev/68247a087e2b

The patch landed in nightly and beta is affected.
:bhearsum, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox106 to wontfix.

For more information, please visit auto_nag documentation.

Comment on attachment 9296383 [details]
Bug 1792546: add exe metadata to private_browsing.exe r?nalexander!

Beta/Release Uplift Approval Request

• User impact if declined: Pinning Private Browsing to taskbar in certain ways will result in undesired strings/descriptions on it.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: 1) Install Firefox

2. Go to the installation folder
3. Right click "private_browsing.exe" and pin it to the taskbar

Expected result: The hover text on the taskbar icon should be MOZ_APP_DISPLAYNAME (eg: Firefox Nightly) -- it should NOT be private_browsing

• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch simply adds exe metadata to private_browsing.exe. There are no functional implications that I'm aware of.
• String changes made/needed: no
• Is Android affected?: No

Comment on attachment 9296383 [details]
Bug 1792546: add exe metadata to private_browsing.exe r?nalexander!

Approved for 106.0b7, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/339dd1ac669a

We can still reproduce this issue on Nightly 107.0a1 and Firefox 106.0b7 using Windows 7, WIndows 10 and Windows 11.
We reproduce it in different mode: sometimes the issue is reproducing only on the taskbar, sometimes only in the Start Menu, but the issue is reproducing constantly in a form or another.

Also sometimes the name is only listed as "Firefox". Please look at the attached image.

(In reply to Oana Botisan, Desktop Release QA from comment #11)

Created attachment 9296991 [details]
imgpsh_fullsize_anim (2).png

We can still reproduce this issue on Nightly 107.0a1 and Firefox 106.0b7 using Windows 7, WIndows 10 and Windows 11.
We reproduce it in different mode: sometimes the issue is reproducing only on the taskbar, sometimes only in the Start Menu, but the issue is reproducing constantly in a form or another.

Also sometimes the name is only listed as "Firefox". Please look at the attached image.

Is this on a clean system that hasn't had a previously affected version installed? There's all sorts of caching that could be at play here. At the very least, please check that %appdata%\Microsoft\\Internet Explorer\\Quick Launch\\User Pinned\\TaskBar has no Firefox shortcuts in it -- but preferably STR on a clean system that has never had Firefox installed would be best.

I deleted every registry and deleted everything Firefox related from:

• %appdata%\Microsoft\Windows\Start Menu\Programs
• %appdata%\Microsoft\Internet Explorer\Quick Launch\User Pinned
• %programdata%\Microsoft\Windows\Start Menu\Programs
• %appdata%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar
• C:\ProgramData\Mozilla-1de4eec8-1241-4177-a864-e594e8d1fb38

I can still reproduce the issue when pinning it to the taskbar.

I haven't been able to reproduce this on the taskbar, but I have witnessed it on the Start Menu. It's possible the Start Menu and Taskbar have different root causes, as the Start Menu depends at least partly on the Visual Elements Manifest while the Taskbar does not. (If that were to be causing issues, I would expect firefox.exe to have the same behaviour though -- which it doesn't.)

One more request: can you please reproduce the taskbar instance of this in a clean VM (never had Firefox installed), and see what shows up in %appdata%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar?

It appears that the Start Menu will find and use an existing shortcut if it exists (as does the Taskbar). The best for this is probably to create the shortcut in the installer again (that way it almost certainly exists). I disabled that not long ago for a separate issue, but some of the reasons I do have since changed, so we can probably safely do it again.

I can still reproduce the issue using a VM with Windows 10, but this time the issue is reproducing in the Start menu just like on your machine.
Usually I reproduce the issue while using Windows 10 on the taskbar.

(In reply to bhearsum@mozilla.com (:bhearsum) from comment #15)

It appears that the Start Menu will find and use an existing shortcut if it exists (as does the Taskbar). The best for this is probably to create the shortcut in the installer again (that way it almost certainly exists). I disabled that not long ago for a separate issue, but some of the reasons I do have since changed, so we can probably safely do it again.

I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1794017 for this to avoid adding extra patches on a fixed bug (per release management guidelines).

(In reply to Oana Botisan, Desktop Release QA from comment #16)

I can still reproduce the issue using a VM with Windows 10, but this time the issue is reproducing in the Start menu just like on your machine.
Usually I reproduce the issue while using Windows 10 on the taskbar.

Can you give it a try with this build? It's got the patches from https://bugzilla.mozilla.org/show_bug.cgi?id=1794017 applied to it.

== Change summary for alert #35617 (as of Tue, 04 Oct 2022 17:43:26 GMT) ==

Improvements:

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=35617

Hi Ben! Can you please validate if your patch may have caused the above improvement ? The other patch doesn't seem to have caused it.

We verified the fix with the try build on Windows 10, Windows 7 and Windows 11. The title now is "Firefox Nighlty".

Is this expected? (because as per comment 8 it should be), however in the Start Menu the title is "Firefox Nightly Private Bowsing". Shouldn't the one from the Taskbar have the same title for consistency?

(In reply to Oana Botisan, Desktop Release QA from comment #20)

We verified the fix with the try build on Windows 10, Windows 7 and Windows 11. The title now is "Firefox Nighlty".

Is this expected? (because as per comment 8 it should be), however in the Start Menu the title is "Firefox Nightly Private Bowsing". Shouldn't the one from the Taskbar have the same title for consistency?

If that's the name you're getting, it sounds to me like the patch from this bug has done its job.

In an ideal world Windows would find the shortcuts we're creating from the installer with the patches from https://bugzilla.mozilla.org/show_bug.cgi?id=1794017 -- but we don't have control over whether or not that happens, so unfortunately this is the best we can do at the moment.

(Ideally we would also translate the string in https://searchfox.org/mozilla-central/source/browser/app/pbproxy/module.ver, but we also don't have a way of doing that as far as I know, so we're stuck using the unlocalized MOZ_APP_DISPLAYNAME.)

(In reply to Alex Finder from comment #19)

== Change summary for alert #35617 (as of Tue, 04 Oct 2022 17:43:26 GMT) ==

Improvements:

Ratio	Test	Platform	Options	Absolute values (old vs new)
7%	perf_reftest_singletons id-getter-2.html	windows10-64-shippable-qr	e10s fission stylo webrender	675.96 -> 629.55

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=35617

Hi Ben! Can you please validate if your patch may have caused the above improvement ? The other patch doesn't seem to have caused it.

I would be flabbergasted if this caused a perf change in either direction. This patch merely adds metadata do a Windows exe - as far as I know, there's no way this could affect performance of Firefox.

I verified the fix using latest Nightly 107.0a1 on Windows 10 and the issue is not reproducing anymore. the title changed from “private_browsing” to "Firefox Nighlty" with the icon for the Private Window.

However the issue is still reproducing on Firefox 106.0.

Hi Ben! Did you have a chance to look over this, because the patches uplifted to 106 Beta (https://bugzilla.mozilla.org/show_bug.cgi?id=1792546#c10) did not fix the issue. Are you going make a follow up in this bug, or in bug 1794017?

(In reply to Oana Botisan, Desktop Release QA from comment #24)

Hi Ben! Did you have a chance to look over this, because the patches uplifted to 106 Beta (https://bugzilla.mozilla.org/show_bug.cgi?id=1792546#c10) did not fix the issue. Are you going make a follow up in this bug, or in bug 1794017?

Well, it's too late to do anything about for 106 at this point...

Are you able to reproduce this in a clean environment with 106? Windows does lots of caching for things like this, so unless you can repro in a VM that hasn't had an affected version installed before, caching may be at play.

Yes, the issue is reproducing in the Start menu while using a clean environment with Firefox 106.0. I used a freshly installed VM with Windows 10 x64.

(In reply to Oana Botisan, Desktop Release QA from comment #26)

Yes, the issue is reproducing in the Start menu while using a clean environment with Firefox 106.0. I used a freshly installed VM with Windows 10 x64.

OK, I understand what's happening now. This is fixed in 107 because https://bugzilla.mozilla.org/show_bug.cgi?id=1794017 is fixed there, but was not uplifted to 106. As long as you can't repro in 107, there's nothing to worry about here. Thank you for following up!