Open Bug 1495295 Opened 6 years ago Updated 2 years ago

Nightly's pinned shortcut in the Windows taskbar becomes invalid after every update

Categories

(Firefox :: Installer, defect, P3)

Product:
Firefox
Component:
Installer
Platform:
Unspecified
Windows 10
Type:
defect

Tracking

()

Status:
REOPENED
Tracking Flags:
Tracking Status
firefox89 --- affected

People

(Reporter: itiel_yn8, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [fidedi-ope])

Attachments

(3 files)

White page
37.22 KB, image/png
Details
Can't open this item
28.65 KB, image/png
Details
Process Monitor - rename operation by helper.exe
121.60 KB, image/png
Details
Using Windows 10 x86. For over 2 years, I've had Nightly pinned to the taskbar. This started about a month ago. After every Nightly update, the Nightly icon on the taskbar becomes invalid (and it looks like a white page -- see attached). Symptoms: - When closed, the Nightly icon on the taskbar is a white page - Right clicking the Nightly icon gives only one option- "Close window" - Unpinning is only optional by clicking it and confirming the "Can't open this item" message (see attached), and even then the shortcut file on %appdata%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar is still present. Deleting it is mandatory so the next time I pin Nightly, its description won't be "Firefox Nightly (2)" - This happens ONLY after Nightly updates. Closing and restarting Nightly doesn't make this issue re-appear I've tried reproducing it on a clean Windows 10 x64 install on a VM with no success. I tested it on 2 user accounts, one of them has a username with Hebrew characters (I thought this might be the cause as my main system also has a Hebrew username) and it still worked. I'm at loss now as I can't pinpoint what the reason might be. I thought about checking the regression range but not sure how to do this all while having to update Nightly.
Attached image White page —
Attached image Can't open this item —
This issue seems to be a duplicate of Bug 1404814. So I'll mark it accordingly.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Actually.. this is not a dup of bug 1404814. Here, the icon won't even open Nightly. It's not an icon issue. If the user opens Nightly from the start menu or from the desktop, the Nightly icon will come back, and revert to blank after closing it I did some digging, and for some reason, when clicking Nightly's icon on the taskbar, the system tries to launch: %AppData%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Firefox Nightly.lnk~RF142e76de.TMP (captured from ProcessMonitor) Apparently "~RF142e76de.TMP" is being added to the path, which causes it not to be opened. I've tried reseting the Favorites and FavoritesResolve entried in: HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Taskband reseting all items on the taskbar and repinning them, and and on the next Nightly update the issue got back :(
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Component: General → Shell Integration
OS: Unspecified → Windows 10
I've managed to pinpoint with Process Monitor (by filtering "Firefox Nightly.lnk" in Path and Detail) the moment where helper.exe changes the file name, though I'm not sure why I'm seeing it as a file rename operation and not as a registry key rename operation (in HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Taskband, Favorites and FavoritesResolve entries). Will investigate further in the next update.
helper.exe is part of the installer code so changing component.
Component: Shell Integration → Installer
Thanks for reporting this issue, and for investigating as well. We're very careful to avoid touching the taskbar pin in helper.exe, because it's very fragile; it's tough to keep the file in sync with the registry, and Explorer likes to just remove the pin if anything happens. So we specifically don't rename it or do anything else to it after it's created. I also don't think we have any code anywhere that creates/renames temp files using that ~RF naming convention, I don't recall seeing it before. Do you happen to have AVG antivirus installed (or a different third-party antivirus)? I'm suspicious that this might be caused by something it's doing.
Flags: needinfo?(itiel_yn8)
(In reply to Matt Howell (he/him) [:mhowell] from comment #8) > We're very careful to avoid touching the taskbar pin in helper.exe, because > it's very fragile; it's tough to keep the file in sync with the registry, > and Explorer likes to just remove the pin if anything happens. So we > specifically don't rename it or do anything else to it after it's created. I > also don't think we have any code anywhere that creates/renames temp files > using that ~RF naming convention, I don't recall seeing it before. Yeah, that's what I thought myself, though I had a feeling it calls a Windows API that triggers this behaviour. > Do you happen to have AVG antivirus installed (or a different third-party > antivirus)? I'm suspicious that this might be caused by something it's doing. COMODO Internet Securiry. Not sure if I tried disabling it, will give it a go and update. Thanks!
Flags: needinfo?(itiel_yn8)
(In reply to Itiel from comment #9) > (In reply to Matt Howell (he/him) [:mhowell] from comment #8) > > Do you happen to have AVG antivirus installed (or a different third-party > > antivirus)? I'm suspicious that this might be caused by something it's doing. > > COMODO Internet Securiry. > Not sure if I tried disabling it, will give it a go and update. Nope, disabling all CIS protections didn't seem to help. I'll try next to whitelist helper.exe maybe? One thing I can remember, is that this started to happen right after I've upgraded to Windows 10 1809 from 1803 (on the test VM I had set-up for this to reproduce, I installed Windows 10 1803). Could this be related?
(In reply to Itiel from comment #10) > Nope, disabling all CIS protections didn't seem to help. > I'll try next to whitelist helper.exe maybe? That didn't help either.
I started having this issue yesterday (8 Dec 2018) on Windows Insider Build 18290.1000 x64 using Nightly 65.0a1. It happened before uninstalling Norton Security and installing Bitdefender Total Security 2019. However, it was the first time I had updated Nightly since installing the Insider Build. My symptoms are the same, except for the following: 1. Right-clicking the icon brings up only an option to "Unpin from taskbar" 2. The tooltip on the icon (if I hover over it) is "Nightly (2)" 3. After opening Nightly from Start (the tile has the proper icon and works), it appears in a separate icon on the taskbar as "Nightly (3)" -- I did not remove the incorrect icon before opening Nightly Further testing and results/symptoms: 4. I pinned Nightly (3) and dragged it to the first position on the taskbar while one, multi-tab window was open. Then, I unpinned it while still open. After this, right-clicking the icon brings up two options: "Pin to taskbar" and "Close window" 5. I tested "Pin to taskbar" and even after clicking it, the context menu still shows the same "Pin to taskbar" rather than "Unpin from taskbar" 6. I also tested "Close window" and it works as one would expect 7. Opening new windows via Nightly or Start are grouped with the icon that used to be Nightly (3) 8. Right-clicking the Nightly tile in Start and clicking More > "Pin to taskbar" causes the icon to become "Nightly (3)" again and have a full context menu 9. Unpinning Nightly (3), then opening Nightly again causes the icon to be "Nightly (2)" with the proper logo 10. Pinning Nightly (2) makes it into Nightly (3) which behaves as it did earlier.
Investigation: I checked out "%APPDATA%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar" and found links to "Nightly" and "Nightly (2)" which both open Nightly. I deleted "Nightly (2)" then opened and pinned Nightly. As I expected, it became "Nightly (2)" and created the link with the same name in the TaskBar folder. So, I deleted both links, reopened Nightly, and pinned it. The pinned icon and its link in TaskBar are now called "Firefox Nightly" and work properly while pinned. However, if I unpin it, the same issue with the context menu being incomplete appears. Pinning Nightly to the taskbar from Start creates a new icon called "Nightly" on the tooltip and context menu. The context menu has only two options: "Nightly" and "Unpin from taskbar".
(In reply to IdmFoundInHim from comment #13) > Investigation: > I checked out "%APPDATA%\Microsoft\Internet Explorer\Quick Launch\User > Pinned\TaskBar" and found links to "Nightly" and "Nightly (2)" which both > open Nightly. I deleted "Nightly (2)" then opened and pinned Nightly. As I > expected, it became "Nightly (2)" and created the link with the same name in > the TaskBar folder. So, I deleted both links, reopened Nightly, and pinned > it. The pinned icon and its link in TaskBar are now called "Firefox Nightly" > and work properly while pinned. However, if I unpin it, the same issue with > the context menu being incomplete appears. Pinning Nightly to the taskbar > from Start creates a new icon called "Nightly" on the tooltip and context > menu. The context menu has only two options: "Nightly" and "Unpin from > taskbar". Thanks for investigating on your side too! So, your issue seems very similar to mine, with a slight variation. Just to find shared backgound to see what triggers it on our PCs, a few questions: 1. Do you know what version (and date) of Nightly did you update from? 2. What Windows 10 version (not build) were you on *before* you updated Nightly, if you remember? 3. Is your user account (in C:\Users) in english characters? 4. Not sure I understand correctly from your first comment here: a. Did it happen also when you had Norton? b. Now you have Bitdefender, and it still happens? 5. Does disabling all of your antivirus protection help in any way? Thanks!
Flags: needinfo?(ifihpublic)
1. I will not be able to find out for sure until tomorrow, but it was roughly Dec 4 or 5 Nightly 2. I was on 1809, then upgraded to the Insider 1809, then updated Nightly 3. My user folder is in English, but I have Hebrew installed on my computer (the one that has the issue) 4. The issue showed up right before I uninstalled Norton. Then it happened again after installing Bitdefender 5. I will try tomorrow Another thing, I have another computer with the same insider build on it, but that computer has not had this problem. It is currently still running Norton.
Flags: needinfo?(ifihpublic)
1. No need then. I thought it was about 2 months ago or so. 2. Hmm, so everything was OK on stable 1809? 3. Aha.. same here :) (user folder is in Hebrew though). Related maybe? 4. So, not related to antivirus. Thanks. 5. No need then, I guess. Your other PC also has Hebrew installed?
I do have the Hebrew keyboard installed on the other computer, which is a laptop, but not the language pack. I believe the desktop (the computer with the bug) has the language pack installed. Yes, the bug did not start until after the upgrade to Fast Ring 1809. Could you try the following: 1. Unpin the Nightly icon (or anything related to Firefox) on the Taskbar 2. Open "%APPDATA%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar" in File Explorer (some of the folders along the way are hidden) 3. Delete all Firefox/Nightly-related links in that folder 4. Pin Firefox Nightly to the taskbar from Start 5. Make sure the link in the TaskBar folder is named "Firefox Nightly" 6. Wait until the next update and see if it helps
Flags: needinfo?(itiel_yn8)
(In reply to IdmFoundInHim from comment #17) > I do have the Hebrew keyboard installed on the other computer, which is a > laptop, but not the language pack. I believe the desktop (the computer with > the bug) has the language pack installed. Yes, the bug did not start until > after the upgrade to Fast Ring 1809. Interesting. The VM mentioned in my first comment here was installed as 1803 (and the bug could not be reproduced there); AFAICR this started right after updating to 1809 on my main PC, and you're saying you were on normal 1809 and everything worked fine then. So this seems to suggest the OS version is not to blame (?). Though, I do remember the Windows version I installed on the VM was a pure Hebrew, while my main system was English & converted to Hebrew afterwards via language pack. Maybe I can try to install English 1809 on a different VM and convert to Hebrew, and re-test things. An easier test would be to revert every language setting back to English and see if Nightly updates correctly. > Could you try the following: > 1. Unpin the Nightly icon (or anything related to Firefox) on the Taskbar > 2. Open "%APPDATA%\Microsoft\Internet Explorer\Quick Launch\User > Pinned\TaskBar" in File Explorer (some of the folders along the way are > hidden) > 3. Delete all Firefox/Nightly-related links in that folder > 4. Pin Firefox Nightly to the taskbar from Start > 5. Make sure the link in the TaskBar folder is named "Firefox Nightly" > 6. Wait until the next update and see if it helps No, it does not :(
Flags: needinfo?(itiel_yn8)
Okay, I just updated my desktop's Nightly from 9 Dec (65.0a1) to 11 Dec (66.0a1) and the bug did not show up! All my Language setting are/were set to English. There is an Insider Build update available. I will install that and see if it changes anything.
(In reply to IdmFoundInHim from comment #19) > Okay, I just updated my desktop's Nightly from 9 Dec (65.0a1) to 11 Dec > (66.0a1) and the bug did not show up! All my Language setting are/were set > to English. > There is an Insider Build update available. I will install that and see if > it changes anything. Just updated Nightly (the second time today) and the issue is still there. It that a third computer? (previously you said your desktop is with a Hebrew lang pack) If so, is there any special configuration you can tell about it? Antivirus? Is it also in the Fast Ring? Is it normal 1809? 1803? Do you run Nightly with a profile that is not located at the same drive as Nightly itself, by any chance?
That is the same computer; I meant I didn't have Hebrew active for input, display language, etc. No, the profile and Nightly are on C: My profile ("default", with Sync on and connected to a Firefox account) is located in "%APPDATA%\Local\Mozilla\Firefox\Profiles" and Nighlty is in "C:/Program Files". I also have a bug testing profile in the same location.
(In reply to IdmFoundInHim from comment #21) > That is the same computer; I meant I didn't have Hebrew active for input, > display language, etc. Interesting. I'll try doing the same soon-ish. Thanks!
For now, my computer (the desktop that previously exhibited this problem) no longer does exhibit this bug.
(In reply to IdmFoundInHim from comment #23) > For now, my computer (the desktop that previously exhibited this problem) no > longer does exhibit this bug. That's *after* you switched back to English UI for Windows, right? Meaning that if you were to switch again to Hebrew, the issue will probably re-appear?

My parents get either this or the pinned taskbar item gone altogether with every update it seems.

Summary: After every update to Nightly, its pinned item in the Windows taskbar becomes invalid → Nightly's pinned shortcut in the Windows taskbar becomes invalid after every update
See Also: → 1532081
See Also: 1532081 →

Sharing an update here that was in bug 1532081:

(Quoting Matt Howell (he/him) [:mhowell] from bug 1532081 comment #1)

This has a good chance of being related to bug 1532093, which is being worked on.

We believe this should have been fixed by bug 1510276 and/or bug 1532093. Both of those are in Firefox 67, so if anyone who's been having this problem could test on that version (either on beta or after it releases), that would be helpful. Note that that means already having a build of 67 and updating from it to a newer build in order to have both fixes present.

Priority: -- → P3

Months later, the issue still appears after every FF update (currently on 68.0.1 64-bit).
I already end up switching temporarily to Chrome every time I get too tired to fix it, and I believe many users have as well - maybe even permanently.

Any idea about what can be causing it?

I really don't have anything, sorry. I'd certainly welcome any suggestions anyone might have, but I haven't been able to see this happen myself, so I don't have any real idea what might be causing it. Everything that's been proposed so far in this bug as potentially correlated has been ruled out as far as I can tell.

See Also: → 1675918

Still seems to happen for every minor update on Thunderbird - maybe you can try Thunderbird for testing?

I also have this problem (Firefox icon in taskbar disappears) on a PC running Windows 10 home (latest version) It doesn't happen on my other PC which runs Windows 10 Pro.

I have also encountered this issue while updating from Firefox 87.0b1 x64 to latest beta 89.0b12. After restart the pinned icon appears as a white page. This only happens with .exe files on my end.

status-firefox89: --- → affected

Any update on this? Looks like taskbar pinning is generally broken on Windows 10 for Firefox and Thunderbird (at least on ESR). We just created the umpteenth duplicate and checked some registry entries. Perhaps bug 1756293 comment #2 (and above) is worth reading. Happy to help with debugging.

Flags: needinfo?(mhowell)

Not seeing the issue here with either application.

How do I reproduce?

We've just done this: On a recently installed Windows 10 system, as admin user, downloaded the full FF installer (not the stub installer), currently at version 97. Double clicked the installer, performed a custom install, accepted all the defaults, except the maintenance service. Result: FF installed, desktop icon present, no taskbar icon present, so pinning didn't take place. A similar install of FF 91.6.0 on an different machine also yielded no taskbar pinned icon.

Some more observations: If one installs TB and then drags the desktop shortcut (not the executable) to the taskbar (or uses "Pin to Taskbar"), then the pinning survives the next install. It also shows up in C:\Users\xxxx\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar. That's different to what the installer tries to achieve, right?

All the TB/FF installers we tried failed to pin to the taskbar.
If you manually pin/drag the desktop shortcut to the taskbar, it survives a subsequent installation.
If you manually pin/drag the executable to the taskbar, it does not survive a subsequent installation. Instead, the shortcut is moved to C:\Users\xxxx\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Tombstones. Not a surprise since Windows like notices that the executable is overwritten.

One possibility is that all people who ever pinned the desktop shortcut to the taskbar are set for life, the other ones aren't.

So WaltS48, if you want to reproduce, the procedure could be:
Unpin any TB/FF icons from the taskbar.
Remove C:\Users\xxxx\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar
Uninstall TB/FF.
Remove the following registry entries:
HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox and HKEY_CURRENT_USER\SOFTWARE\Mozilla\Thunderbird
This should give you a pretty clean starting point.

Then install TB/FF via the EXE installer, looks like the MSI installer manages the pinning (would have to double check).
This should pin the icon to the taskbar, but fails to do so.

See Also: → 1756331

There appear to be at least four ways to do manual pinning:

  1. the EXE 2) the running program from the taskbar entry 3) the desktop shortcut (if present) 4) the start menu entry (if present).
  2. doesn't survive a new installation and 2) behaves a little differently: The pinned icon is only visible if the program doesn't run.
See Also: 1756331 →

(In reply to Rachel Martin from comment #35)

Any update on this?

I think that we are still fairly stuck on figuring out how to reproduce this problem. I don't really know how we can fix this problem without being able to reproduce it.

Looks like taskbar pinning is generally broken on Windows 10 for Firefox and Thunderbird (at least on ESR).

I do not agree that it's generally broken. I just tried reproducing this bug with ESR Firefox on Windows 10 and I still cannot reproduce the issue on my machine.

Happy to help with debugging.

I think that we mainly just need help reproducing the issue ourselves. Like I said, it's going to be very difficult for us to fix this if we can't reproduce the problem.

(In reply to Rachel Martin from comment #38)

We've just done this: On a recently installed Windows 10 system, as admin user, downloaded the full FF installer (not the stub installer), currently at version 97. Double clicked the installer, performed a custom install, accepted all the defaults, except the maintenance service. Result: FF installed, desktop icon present, no taskbar icon present, so pinning didn't take place. A similar install of FF 91.6.0 on an different machine also yielded no taskbar pinned icon.

So, to be clear, this bug is about an existing pin becoming invalid after Firefox updates. It's not about the Firefox installer not pinning Firefox to the taskbar. We are aware that the installer doesn't do that on modern versions of Windows. This is because Microsoft changed things such that we cannot easily set that pin anymore. We actually do have a way of attempting to set the pin despite this, but we do not currently call it from the installer.

Side note: Let's refrain from needinfo'ing :mhowell about this. She doesn't work on this anymore.

Flags: needinfo?(mhowell)
Whiteboard: [fidedi-ope]

OK, we were wondering about the desired behaviour. So no pin at installation, only maintaining an existing one. So which existing one should be maintained? As detailed in (sadly misformated) comment #41, there are (at least) four ways to pin, and only pinning the EXE doesn't survive. If the installer doesn't pin, then it would just be a matter to tell people to use one of the other three methods.

(In reply to Rachel Martin from comment #43)

pinning the EXE doesn't survive

What do you mean by pinning the EXE?

Well, the Windows UI offers "Pin to taskbar" in various locations. In comment #41 we had:

  1. Navigate to EXE in program folder, context menu, or via dragging to the taskbar
  2. Start the program and then use the context menu on the taskbar entry/button of the running program
  3. Context menu or dragging of desktop shortcut
  4. Context menu or dragging of start menu entry.
    As far as our testing goes, only 2-4 survive a subsequent installation, 1. creates a tombstone (comment #40).

I have been having this problem with Firefox beta recently, and the way I've always pinned is to start Firefox (from the start menu), and then right-click on the taskbar entry and select 'Pin to taskbar'. I've done this 15+ times in the last couple of months or so due to the pinned entry either becoming invalid or disappearing.

I've now cleaned up %APPDATA%\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar and pinned from the start menu instead, and so will see if it happens again on the next update.

(In reply to Rachel Martin from comment #45)

  1. Navigate to EXE in program folder, context menu, or via dragging to the taskbar
    ...
    As far as our testing goes, only 2-4 survive a subsequent installation, 1. creates a tombstone (comment #40).

If I am understanding correctly, you are finding firefox.exe and dragging it to the taskbar. I tried this and, after updating, the taskbar pin still works for me.

(In reply to Reupen from comment #46)

the way I've always pinned is to start Firefox (from the start menu), and then right-click on the taskbar entry and select 'Pin to taskbar'.

I tried this as well and the pin still works for me after updating.

Sorry that this so difficult to figure out. I really can't imagine what is happening differently on your machines compared to mine.

(In reply to Kirk Steuber (he/him) [:bytesized] from comment #47)

If I am understanding correctly, you are finding firefox.exe and dragging it to the taskbar. I tried this and, after updating, the taskbar pin still works for me.

Actually, via the context menu "Pin to Taskbar". Then re-installed from Firefox Setup 91.6.0esr.exe and the taskbar icon was gone. The shortcut is now in C:\Users\xxxx\AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar\Tombstones (as stated in comment #40).

(In reply to Rachel Martin from comment #48)

Actually, via the context menu "Pin to Taskbar".

Was that a right-mouse-button-drag which opened the context menu when dropped on taskbar?

Then re-installed from Firefox Setup 91.6.0esr.exe and the taskbar icon was gone.

Could "reinstalled" be the keyword here? Maybe the original exe is removed first, and Windows notices the broken link and acts on that by removing the pinned link?

(In reply to Thomas D. (:thomas8) from comment #49)

Was that a right-mouse-button-drag which opened the context menu when dropped on taskbar?

Right-click/context menu on the .EXE, "Pin to Taskbar", no dragging.

Could "reinstalled" be the keyword here? Maybe the original exe is removed first, and Windows notices the broken link and acts on that by removing the pinned link?

See comment #40 for prior comment: "Not a surprise since Windows like(ly) notices that the executable is overwritten".

See Also: → 1778783
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 5 See Also bugs.
:Amir, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(ahabibi)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(ahabibi)
Blocks: 1778783

(In reply to BugBot (nomail) [:suhaib / :marco/ :calixte] from comment #52)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Yes it's still happening. Just now updated Firefox and the issue repeated again.

Icon will disappear from taskbar and trying to open will show a "No program found" error message.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: