1756331 - Firefox does not bind to taskbar icon when launched after an update

Status: RESOLVED DUPLICATE of bug 1751153

(Core :: Widget: Gtk, defect)

Description

[Oliver Hiorns [:oshbug]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:99.0) Gecko/20100101 Firefox/99.0

Steps to reproduce:

Open firefox by clicking on the taskbar icon (KDE Plasma, Wayland, Manjaro Linux) when an update was queued to be installed.

Actual results:

Firefox opens fine, but creates a new "generic application" icon in the taskbar, rather than associating itself with the pinned/existing icon. There are now 2 icons in the taskbar because of firefox - one because I pinned it, which has the correct icon and has no windows, and one with a generic icon which has the new window associated with it.

Expected results:

Firefox opens with the new window associating itself with the existing pinned icon.

Comment 1

[Oliver Hiorns [:oshbug]]

Since this seems to be happening only when an update is queued to be installed, my best guess is that the cause is the newly launched firefox presenting itself as the auxiliary "updater" program rather than "firefox", and as a result the host desktop environment does not realise it is firefox and so does not bind it to the desktop icon accordingly.
The issue is fixed by closing and reopening firefox, since then it launches without updating, but since I use nightly, I experience this issue almost every time I launch firefox (and it is also inconvenient to debug since I can only gain insight when an update is available).

Also, while I am on KDE Plasma Wayland on Manjaro Linux, my friend uses MacOS and reports similar symptoms (duplicate firefox icons in the dock when launched if an update is queued, although in his case the icon is correct - however it still is duplicated).

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Oliver Hiorns [:oshbug]]

I have changed the Component to Widget, since this issue seems to occur on multiple platforms (Linux, macOS). Specifically it seems to be to do with the updater, but I cannot find a more appropriate Component tag.

Regarding the linked thread 1495295, it may be related, but also seems to be significantly different. For one thing, it seems to be rather windows-focused, whereas I do not know of any instances of this bug on Windows, but more specifically, for me, the icon is never broken. If I close and re-open firefox after seeing the issue, everything is back to normal immediately, with no need to set up the shortcut again.
I think that the issue is not related to invalidating the link - since I'm on linux, the link is a desktop file which I created myself, so as long as firefox doesn't stop containing a firefox executable I don't see how it could break. The issue seems to be the DE not recognising the launched application as "firefox" at all when it launches after applying an update.

Comment 4

[Stephen A Pohl [:spohl]]

The fix for this will be different for each platform and is being tracked separately for macOS. This should remain a Widget:Gtk bug.

Comment 5

[Oliver Hiorns [:oshbug]]

Ah, alright - sorry.

Since earlier I've checked the window class using KDE's inbuilt "configure special window settings" menu, and since an update was queued, I was able to compare the name firefox was registering itself with when updating and when launching normally.
I found that when updating, it was registering itself as nightly, whereas normally it was registering itself as firefox-nightly.

After this, I checked my .desktop file and it seems that I added an extra argument, --name nightly, which I seem to recall was part of an effort to fix this issue myself some months ago. (Curiously, this argument still functions and yet now is undocumented?) I removed this, and found that upon a normal start, the registered name was firefox-nightly.

There hasn't been an update yet, so I can't confirm that this has fixed the issue, but it seems likely it has, if the registered name is now consistent with how it was during an update.

However, this does look like flags are getting lost in the updater, since it looks like what happened was firefox --name nightly → updater → firefox, which doesn't seem like intentional behaviour.

I'll report back on whether this has completely resolved the issue once an update is available so I can verify.

Also, sorry for the wasted time, since it seems like this issue was fixed a while ago, and it was my own fault (due to a failed attempt to fix it) that the problem remained for me.

Comment 6

[Oliver Hiorns [:oshbug]]

Can confirm, that did fix the issue.

Should I open a separate issue for the updater not properly forwarding on launch arguments to the newly spawned firefox after updating?