Affected versions

• 82.0 (20201014125134)
• 83.0b3 (20201022171613)
• 84.0a1 (20201022215159)

Affected platforms

• Windows 10x64 & x86

Steps to reproduce

1. Open Firefox and set it as the default browser.
2. Change the clock with 24h onward.
3. Open Edgium and set it as the default browser.
4. Change the system clock with 24h onward.
5. After the notification is displayed open Firefox again and observe the icon. (close and reopen if already opened)

Expected result

• The browser icon is displayed as expected.

Actual result

• Firefox has no icon displayed.

Regression range

• I will search for one ASAP.

Notes

• Attached a screen recording: link.
• Firefox shortcut default path is changed to C:\Program Files\Mozilla Firefox\default-browser-agent.exe instead of firefox.exe.
• Uninstalling and reinstalling Firefox doesn’t fix the problem. Opening Start Menu -> Programs folder and delete the firefox shortcut makes the shortcut icon to be displayed.

Suggested Severity: S3

I tried the STR, and I cannot reproduce the issue. But I talked to Adam, who said he was able to reproduce it in a VM. Perhaps he can shed some more light on what's going on here?

I was able to reproduce in a Windows 10 Home (2004) VM with an install of 82.0.1, by running the WDBA task from the task manager instead of changing the clock.

1. once after setting Firefox as the default browser
2. then after changing it to Edge

at which point the default-agent.exe shortcut called Firefox appears in the start menu in place of the correct one.

It looks like the shortcut is being created by WinToast: Initialize(), calls createShortcut(), which checks (via validateShellLinkHelper()) an existing shortcut with the app name (which we set to MOZ_APP_BASENAME, "Firefox") for a matching AUMI, changing it if it doesn't match. But if the shortcut doesn't exist, it will create it in createShellLinkHelper().

The problem is that it looks for the shortcut under %APPDATA%, which will give the user's start menu directory (e.g. C:\Users\Adam\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Firefox.lnk) instead of the system start menu dir (C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Firefox.lnk). With an elevated install we write into the system start menu, so WinToast won't find the shortcut, instead creating one in Roaming, which shadows the correct shortcut from ProgramData.

This seems to be done because notifications don't work correctly if there isn't a matching shortcut in the start menu; if I delete the system shortcut before the prompt shows, it will not have the buttons, and sometimes won't even show a "Firefox" caption (instead showing the AUMI). Some older docs claim that notifications don't work at all without a shortcut. When the shortcut code was added to WinToast the commit said "Use a custom abstract model for the WinToastHandler". I don't think the shortcut being created by WinToast is really doing what it is meant to do, given that we initialize WinToast immediately before showing the notification.

Our start menu shortcut on release is BrandShortName, on an official build this is "Firefox", so it should be able to find it, but because it's looking in the wrong it creates a new one. But just fixing that check won't help, on other channels a Firefox.lnk shortcut is still written, and I think because it uses the same AUMI as the real shortcut, only one is shown in the start menu, even though it has a different name (e.g. "Firefox Nightly").

I think we should:

1. stop WinToast from making a shortcut
2. probably not try to show the notification if there wasn't a compatible shortcut there already, this should be fairly rare
3. clean up, in install/uninstall/postupdate, these erroneously created shortcuts

I'm not sure what's a good way to figure out whether 2 applies, a malformed notification may appear if we don't check. Maybe best to fix 1 and 3 and leave that for later?

Kirk, does any of the above suggest why you couldn't reproduce this?

Yeah, I think I understand why I couldn't reproduce.

I tried searching for a regression range on Windows 10x64 but with no luck, because the issue is reproducible with Firefox 80.0a1 (20200702214948) and Firefox 80.0b1 (20200728204253) so I think it's safe to assume that this is not a regression.
Removing the flags accordingly. If anything else is needed please let me known. Thank you!

The severity field is not set for this bug.
:mossop, could you have a look please?

For more information, please visit auto_nag documentation.

Fixes WinToast failing to find the shortcut to check its AUMI because:

1. the app name given to WinToast did not match the shortcut name, and
2. it wasn't looking in the system-wide Start Menu.

Further, adds an option to fail if shortcut isn't found, rather than create it, because:
a) the shortcut would be to the WDBA, which is not useful, and anyway
b) we're showing the notification immediately after initializing WinToast, which
is too soon for Windows to reliably pick up on it, so it usually doesn't have the
desired effect of allowing the custom abstract model.

This patch handles 1 & 2 from comment 2 (don't create the shortcut, don't try to show the notification if no matching shortcut was present), but I'm leaving 3 (remove shortcuts that were created accidentally) for followup bug 1681207, I'm not sure about how to address it yet.

https://hg.mozilla.org/mozilla-central/rev/f516fd94ae85

The issue is verified fixed with Firefox 85.0a1 (20201208213457) on Windows 10x64 by following the steps from comment 0. The Firefox icon is correctly shown after the notification is displayed.