In the German Firefox support we already got reports from three users that the Firefox logo on their desktop changed to a PDF logo after the update to Firefox 100.

The release notes mention:

New users can now set Firefox as the default PDF handler when setting Firefox as their default browser.

Maybe it's related to this work?

[Tracking Requested - why for this release]:

While it's not causing issues for using Firefox it seems pretty bad that it's more difficult for affected users to recognize their browser.

This will be a regression from Bug 1761389. Somehow, we have users who have taskbar icons with an unexpected icon ID. I'm not quite sure how to get users to tell us what the taskbar shortcut configuration icon ID is. mhowell, perhaps you just know how to extract this from the relevant .lnk?

Sorry -- NI to mhowell for:

Somehow, we have users who have taskbar icons with an unexpected icon ID. I'm not quite sure how to get users to tell us what the taskbar shortcut configuration icon ID is. mhowell, perhaps you just know how to extract this from the relevant .lnk?

Set release status flags based on info from the regressing bug 1761389

Truth be told, I usually parse LNK files by just looking at them in a hex editor. I don't know if I would recommend that, but I don't know of a good tool for this either. I think this is the best I can do, here's a Powershell command that should print the icon index:

(New-Object -COM WScript.Shell).CreateShortcut("~\AppData\Microsoft\Internet Explorer\Quick Launch\User Pinned\Taskbar\Firefox.lnk").IconLocation

The file name may or may not be correct; it's probably best to verify it in the shortcut properties window.

The severity field for this bug is set to S3. However, the bug is marked as tracked for firefox100 (release).
:nrishel, could you consider increasing the severity of this tracked bug?

For more information, please visit auto_nag documentation.

Do we have any leads on this bug? Probably too late to address in a dot release for 100, but maybe for 101 still before it goes to RC next week?

(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)

Do we have any leads on this bug? Probably too late to address in a dot release for 100, but maybe for 101 still before it goes to RC next week?

No, I have no leads. I'm moderately confident it's not even our bug: there are lots of terrible interactions and caching artifacts with this part of Windows, so it's as likely that we've tripped some latent Windows issue as that we've done something wrong ourselves. But of course, we would like to avoid whatever is happening. I've not had much chance to investigate but I'll try to see if some of the taskbar pinning actions we take in-product can trigger this. Leaving NI as a reminder.

(In reply to Release mgmt bot [:suhaib / :marco/ :calixte] from comment #5)

The severity field for this bug is set to S3. However, the bug is marked as tracked for firefox100 (release).
:nrishel, could you consider increasing the severity of this tracked bug?

Nicholas and I have discussed: we think this is a Windows shell caching issue that will be seen (perhaps intermittently after upgrade) by some small population. S3 seems correct.

Follow on discussion with nalexander: assigning nalexander as these changes fall under their area, dropping priority as there is a decent chance this is a bug in the Windows shell cache and outside our control.

Nick and I did a pretty deep dive on this and here's what we discovered.

I had three shortcuts on my desktop where this happened; these were shortcuts that I created manually.

When we looked into these shortcuts, they all had the icon index set to 5. We then verified that in the normal creation of shortcuts, the index is 0.

In looking at Firefox versions prior to 100, we have six icons in our EXE; the first five icons have IDs of 1 through 5 (see https://searchfox.org/mozilla-central/source/toolkit/xre/nsNativeAppSupportWin.h).

The sixth icon is a special icon IDI_APPLICATION (32512), but importantly it is the same visually as the first icon and when you select as the icon (probably using Shortcut->Change Icon in properties), it is set as index 5. The indexes are 0 based and reflect the position of the icon within the EXE, they are not related to the ID of the icon.

In Firefox 100, we introduced the PDF icon and it became the sixth icon in the executable. So if a shortcut was set to use the last index prior to 100 (5), it now pointed to the PDF icon.

So this situation could be created one of two ways.

1. When a user created a Firefox shortcut, they manually set the icon in properties and set it to the last Firefox logo instead of the first one.
2. At some point in the past, Windows set the default icons of shortcuts to the last icon instead of the first one.

I tend to lean toward 1, but it's been so long since I created those shortcuts, I don't remember, and I can't speak for the reporter of this bug.

All that being said, this is rare enough that we don't think there is anything we can do here and we should probably close as WONTFIX.