1557747 - Cannot drag and drop Firefox from the start menu to the taskbar

Status: NEW

(Firefox :: Installer, defect, P3)

Description

[Daniel Cicas [:dcicas], Release QA]

Attachment: taskbar.PNG

Affected versions

• Fx 68.0b8
  Fx 65.0.2

Affected platforms

• ARM64 Windows 10
  Windows 10

Steps to reproduce

1. Install Firefox.
2. Go to the folder where Firefox is installed and right click on firefox.exe.
3. Select "Pin to Start".
4. From the start menu drag and drop the Firefox icon to the taskbar.

Expected result

• The Firefox icon is dragged and dropped on the taskbar.

Actual result

• The Firefox icon cannot be added to the taskbar with this method.

Regression range
Will return with a regression window as soon as possible.
This issue is not a recent regression as it happens with Fx 65.0.2

Comment 1

[:Gijs (he/him)]

How sure are we this isn't a Windows issue?

Comment 2

[Daniel Cicas [:dcicas], Release QA]

Hello,

I just tried using the same steps but with Chrome.exe and I could add it to the taskbar.

Also while investigating this issue I came across something rather interesting. That If you use the steps above but on the Firefox shortcut that is usually on the desktop, then you can drag and drop it from the from Start and pin it to the taskbar, so this issue seems to only affect the firefox.exe file when added to the start menu.

Comment 3

[:Gijs (he/him)]

:agashlin, do you have any idea what's going on here? (Also, is there a better component for this? Firefox's own file handling isn't really involved here. Maybe Core :: Widget: Win32 ?)

Comment 4

[Masatoshi Kimura [:emk]]

Works for me with 67.0.2 on Windows 10 IP build 18912.

Comment 5

[Adam Gashlin (he/him) [:agashlin] (ex-moco)]

tl;dr: I suspect this is a Windows bug, or misfeature, when the underlying Start Menu shortcut gets replaced by another installation.

mhowell may have more insight into the taskbar, but here's what I found:

I was able to reproduce this on Windows 10 Home, ARM64, version 1803, build 17134.799 after some steps I didn't record. The icon in the start menu was lowercase "firefox" (vs "Firefox" when it was working). The lowercase, nonworking shortcut is from C:\Users\Adam\AppData\Roaming\Microsoft\Windows\Start Menu\Programs instead of C:\ProgramData\Microsoft\Windows\Start Menu\Programs.

I think Start Menu tiles need to have an underlying Start Menu shortcut. "Pin to Start Menu" on an exe will create a shortcut (in Roaming) if a shortcut with the same target doesn't already exist in the Start Menu. It will have the same name as the file (thus "firefox"). But the created shortcut doesn't have whatever magic is needed for the taskbar, which the installer provides in the shortcuts it creates (AppUserModel ID?).

I think I had the ARM64 version in C:\Program Files\Mozilla Firefox, and I installed the win32 version in C:\Program Files (x86)\Mozilla Firefox. The win32 installer overwrote the "Firefox" shortcut in ProgramData, so pinning the ARM64 exe produced the un-draggable lowercase tile. If that's the issue then bug 1558320 (which I'm currently reviewing) might prevent this from happening in the future.

I can reproduce this kind of behavior with chrome.exe by removing it's shortcut in C:\ProgramData\Microsoft\Windows\Start Menu\Programs. And I can fix it for firefox.exe by copying the proper Firefox shortcut off the desktop into the Start Menu\Programs in Roaming or ProgramData.

I thought that doing "Pin to Start" from the Desktop shortcut copies that shortcut into the start menu, but that doesn't seem to be working anymore, if it ever did (it's creating a "W~1871874" tile that doesn't work at all). Maybe the shortcut on your desktop is for the new install which has a Start Menu shortcut.

---

P.S. Oddly, when I removed the initially installed taskbar pin, it seems to just hide the icon. I can still right click it to get the menu, and it takes up space in the taskbar. This seems to have gone away after a reboot and Windows update.

P.P.S. Sometimes "Pin to Start Menu" doesn't even create the un-draggable shortcut. I saw it create nonworking tiles starting with "W~" a few times, and I crashed the Start Menu trying to drag out an icon for which I'd deleted the underlying shortcut.

Comment 6

[Molly Howell (she/her) (no longer active)]

I didn't even know dragging off the start menu into the taskbar was a feature that existed, but your analysis is sound; I've often lamented how easy it is to get one of those broken W~ tiles created, but as you've seen it appears to be more a design flaw than anything else.
Bug 1558320 won't totally prevent this, but it should help by making it harder to get multiple copies installed when you didn't mean to. The only way to totally prevent it would be to actually install a new shortcut for each copy, but that runs into the problem of what to name those shortcuts that is informative and doesn't look silly. I've been thinking about that problem already due to the issues around install-specific profiles, and I don't have an answer for that question yet.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[:Gijs (he/him)]

This isn't really Firefox's file handling, but Windows', so I'm moving it to installer based on comment 6 and the fact that bug 1558320 lives there.

Comment 9

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

This issue is not a regression. I have tested this from Firefox 45.5esr to 72.0.2 and Fx 73.0b11 with "Firefox Setup .exe" builds the scenario from description is working properly, but with "firefox-.zip" installation this issue seems to be present on every builds. That's why I removed the regression-window wanted keyword.