1792547 - When Private Window is pinned to the Taskbar the icon transforms into a normal icon

Status: RESOLVED FIXED

(Firefox :: Private Browsing, defect, P1)

Description

[Oana Botisan, Desktop QA]

Attachment: normal icon.gif

Found in

• Firefox 106.0b4

Affected versions

• Firefox 106.0b4

Tested platforms

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

Steps to reproduce

1. Install a x32 build for Firefox and open it.
2. Open a Private Window and pin it to the taskbar.
3. Uninstall Firefox and install it again without deleting anything.
4. Open a Private Window and pin it to the taskbar.

Expected result

• The Private Window icon is displayed on the taskbar.

Actual result

• A Normal Window icon is displayed on the taskbar.

Regression range

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

Additional notes

• If the icon is clicked then a Normal Window is opened.
• On Windows 7 the issue is reproducing on x64 builds and on Windows 10 the bug is intermittent on x64 builds.

Comment 1

[[e-mail] (:bhearsum)]

I was not able to reproduce this. Is this a clean set-up, or could it have had lots of old Firefox builds, registry entries, etc. on it? I would love to get the contents of these folders before and after the second pin attempt:

• %appdata%\Microsoft\Windows\Start Menu\Programs
• %appdata%\Microsoft\Internet Explorer\Quick Launch\User Pinned
• %programdata%\Microsoft\Windows\Start Menu\Programs

If there's any Firefox shortcuts in there, please attach them to this bug.

I would also be interested in knowing if this is reproducible in a clean environment (preferably a VM that has never had Firefox installed).

Comment 2

[Oana Botisan, Desktop QA]

The way I tested this was by deleteing the registry entries from Computer\HKEY_CURRENT_USER\SOFTWARE\Mozilla and installed Firefox and opened it with a dedicated profile. For that I used the commands:

• rd /s /q %userprofile%\AppData\Roaming\Mozilla
• rd /s /q %userprofile%\AppData\Local\Mozilla
• rd /s /q %userprofile%\AppData\LocalLow\Mozilla
  I opened a Private Window and pinned it to the taskbar and unpin it.
  After that I uninstalled Firefox and installed it again. Opened a Private Window and pinned it to the taskbar.

AR: A Normal Window icon is displayed on the taskbar.

Note:
There is nothing in that remains in these folders about Firefox shotcuts:

• %appdata%\Microsoft\Windows\Start Menu\Programs
• %appdata%\Microsoft\Internet Explorer\Quick Launch\User Pinned
• %programdata%\Microsoft\Windows\Start Menu\Programs

I tried using a WM as well with Windows 10. I can still reproduce the issue by using the steps from comment 0.

Comment 3

[[e-mail] (:bhearsum)]

Thank you very much for the extra information! I was finally able to reproduce this. Here's what I think is happening:

• After the first install, a Private Browsing shortcut is created at startup time. A pref is set in the profile to ensure we never try to create it again.
• Because the Private Browsing shortcut exists, pinning using the Windows context menu works fine.
• The Private Browsing shortcut is removed during the install
• After the reinstall, the same profile is used, and because the earlier pref is set, we don't create a Private Browsing shortcut.
• When the Windows context menu is used to pin this time, there's no Private Browsing shortcut, which causes Windows to create its own with completely inappropriate data.

This is essentially the same bug as https://bugzilla.mozilla.org/show_bug.cgi?id=1762994, except it happens more rarely now because a Private Browsing shortcut exists in the vast majority of cases. For a brief time we were also creating the shortcut in the installer to avoid this exact problem, but we turned that off due to localization issues (https://bugzilla.mozilla.org/show_bug.cgi?id=1790809).

The main reason https://bugzilla.mozilla.org/show_bug.cgi?id=1790809 was an issue was because the way in which we currently check for a matching shortcut is by filename, which means if the installer string and the browser string mismatch, we end up with two shortcuts. This is done to minimize I/O, which was all done on the main thread when it was originally written. Very recently, this I/O has all moved to background threads, so the best option here may be to enhance our shortcut detection. These days, the best option is likely to check the target of the shortcut -- which both points to a specific install directory, and points to a distinct binary for regular and private browsing shortcuts.

Taking this approach would mean turning on shortcut creation in the installer again, which may mean this cannot be fixed until 107 as we're well past the 106 string freeze.

Comment 4

[Romain Testard [:RT]]

Hi, this does not seem to fit the S2 definition( (Serious) Major functionality/product severely impaired or a high impact issue and a satisfactory workaround does not exist ).
The impact is that the wrong icon gets displayed and this happens in a corner case scenario (see STR) - I'm downgrading to S3 for this reason

Comment 5

[[e-mail] (:bhearsum)]

(In reply to Romain Testard [:RT] from comment #4)

Hi, this does not seem to fit the S2 definition( (Serious) Major functionality/product severely impaired or a high impact issue and a satisfactory workaround does not exist ).
The impact is that the wrong icon gets displayed and this happens in a corner case scenario (see STR) - I'm downgrading to S3 for this reason

Thanks for the clarity! I'll treat this as lower priority as the other open follow-ups; I think I may still be able to get a fix in for 106 or 107 though. (It's fairly straightforward, so I figure I may as well do it while it's fresh in mind.)

Comment 6

[Ciprian Georgiu, Desktop QA]

Thanks Ben and Romain for your input!

In respect to what Romain said about the severity of this bug, we’re still inclined to believe that the severity gravitates more towards an S2 rather than an S3. We’re concerned about the users who have already used this feature and are trying to reinstall Firefox, which may be a common scenario. And also, this can be reproduced constantly on Win 7 x64 and on Win 10 x64, the issue seems to be intermittent.

Comment 7

[[e-mail] (:bhearsum)]

(In reply to Ciprian Georgiu [:ciprian_georgiu], Release Desktop QA from comment #6)

Thanks Ben and Romain for your input!

In respect to what Romain said about the severity of this bug, we’re still inclined to believe that the severity gravitates more towards an S2 rather than an S3. We’re concerned about the users who have already used this feature and are trying to reinstall Firefox, which may be a common scenario. And also, this can be reproduced constantly on Win 7 x64 and on Win 10 x64, the issue seems to be intermittent.

I can go either way on this -- if we had a regular icon opening Private windows (or the opposite), this would feel much more serious to me. I also suspect (although can't prove) that users are more likely to have pinned Private Browsing through one of our prompts than the Windows UI.

In any case, I'm hoping to fix this for 107 at the latest - I think the main question is whether or not we uplift the fix for 106, assuming it's ready in time.

Comment 8

[[e-mail] (:bhearsum)]

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, and I have a suspicion that it will fix this issue.

Comment 9

[Oana Botisan, Desktop QA]

We verified the fix with the try build on Windows 10, Windows 7 and Windows 11. We couldn't reproduce this issue anymore.

Comment 10

[Oana Botisan, Desktop QA]

This fix can't be verified until it's uplifted in beta, because we initially only could reproduce it on Beta. The issue was not reproducing on Nightly.