1807230 - existing shortcuts can interfere with taskbar pinning in the installer

Status: NEW

(Firefox :: Installer, defect, P3)

Description

[Ina Popescu, Desktop QA]

Note

• Install Firefox from https://download.mozilla.org/?product=firefox-beta-stub&os=win&lang=en-US

Found in

• Firefox 109.0b6

Affected versions

• Firefox 109.0b6

Tested platforms

• Affected platforms: Windows 10
• Unaffected platforms: to be checked

Steps to reproduce

1. Download the Stub Installer
2. Complete the installation

Expected result

• Firefox should be automatically pinned to Taskbar

Actual result

• Firefox is not automatically pinned to Taskbar

Regression range

• We'll search for the appropriate regression.

Comment 1

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

:epopescu, if you think that's a regression, could you try to find a regression range using for example mozregression?

Comment 2

[[e-mail] (:bhearsum)]

Is this always reproducible? If so, is it on a clean system, or one with many previous Firefox installs?

In any case, I don't see a sharp movement in the amount of taskbar pins on Beta, so this is unlikely to be a widespread issue. I'll try to reproduce myself as well.

Comment 3

[[e-mail] (:bhearsum)]

I was unable to reproduce this. Unless we find a way of reliably reproducing this, it's unlikely we'll be able to do anything.

Comment 4

[Bogdan Maris, Desktop Test Engineering]

I also tried on my Windows 10 machine (which I've been using for installing/uninstalling Firefox for a minute now) and I can repro this thing here.

I investigated a bit and I found out that if I uninstall every Firefox from my PC (via Program and Features, Apps & features or using Uninstal.exe inside Fx) I can still see a Firefox Icon pointing to the default path (Program Files/Mozilla Firefox) inside AppData\Roaming\Microsoft\Internet Explorer\Quick Launch\User Pinned\TaskBar. Deleting that icon did solve the problem, If I now use a stub to install Firefox I will have the icon in the taskbar. This does not explain why we had this issue to begin with though, will use some bait and see if I can find something useful.

Comment 5

[Ina Popescu, Desktop QA]

After deleting the shortcut already created in Microsoft/Internet Explorer/Quick Launch/User Pinned/TaskBar, Firefox (installed from https://download.mozilla.org/?product=firefox-beta-stub&os=win&lang=en-US) was properly pinned to the taskbar.
After uninstalling/re-installing Firefox, it was pinned to the taskbar again. Leaving the bug open for further investigation.

Comment 6

[[e-mail] (:bhearsum)]

It sounds like this can be summed as "existing shortcuts can interfere with taskbar pinning". This is not super surprising, and probably relatively rare (shortcuts should always be removed if Firefox was uninstalled with the uninstaller).

It's probably possible to fix this, or at least make it better, by having the installer detect any invalid shortcuts and either remove them or set up the new shortcuts in a way (eg: different name) that won't interfere with the pinning.

I also don't believe this is a regression.

Comment 7

[Masatoshi Kimura [:emk]]

nsWindowsShellService::IsCurrentAppPinnedToTaskbarSync checks a shortcut file under Microsoft/Internet Explorer/Quick Launch/User Pinned/TaskBar directly. It does not care about the shortcut is actually shown in the taskbar. So if a shortcut file exists, Firefox thinks it is already pinned to the taskbar and do not try to pin.

Comment 8

[Masatoshi Kimura [:emk]]

Chromium uses IPinnedList3::IsPinned to check:
https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:chrome/installer/util/taskbar_util.cc;drc=5578b78366de32caf83044e5ea2268e6d91af766;l=152

Comment 9

[Masatoshi Kimura [:emk]]

Hmm, nsWindowsShellService::IsCurrentAppPinnedToTaskbarSync was added recently (bug 1787552). It is unlikely that it is the cause of this bug.

Comment 10

[Nick Rishel [:nrishel]]

NI :nshukla just to get eyes on this since you have recent experience in the area.

Comment 11

[Nipun Shukla]

The change I made is just moving the function higher in the file so I can access it earlier, so I don't think that would have changed anything. It looks like it could be possible to change the behavior so that it checks if the shortcut is actually shown but it might take me a bit to look at it more closely.