2021458 - GNOME doesn't always assign the correct desktop file to Firefox / Web App windows

Status: NEW

(Firefox :: Web Apps, defect, P2)

Description

[Duncan McIntosh [:dmcintosh]]

Whenever the user creates a taskbar tab, it takes a (few) second(s) for GNOME to register that the taskbar tab was created. Once it does, it goes wrong differently depending on whether the user has a desktop entry for Firefox.

• If the user doesn't have a desktop entry for Firefox and they pin a web app, GNOME finds the webapp desktop entry, assigns it to the web app window and PID, then assigns the main Firefox window to the desktop entry.
• If the user does have a desktop entry for Firefox, the webapp window will be incorrectly connected to the Firefox desktop entry since the webapp desktop entry hasn't been discovered yet. When it is, GNOME doesn't reconsider the window's application, so it remains under the wrong one. This means that the icon is wrong and opening it from the overview creates a new window instead of re-opening the existing window like it usually does on GNOME.

I think some of GNOME's behaviour here is really odd, but it's entirely possible the bug's on the Firefox side. I'll take a closer look soon.

Workarounds

If you don't have a desktop entry for Firefox: (this means Firefox doesn't have an icon and doesn't appear in the overview, so you probably installed Firefox from firefox.com) make one!

mkdir -p ~/.local/share/applications
cd ~/.local/share/applications
branch="-nightly" # or "" if release, "-beta" probably for beta, "-dev" for developer edition
wget https://raw.githubusercontent.com/mozilla/sumo-kb/refs/heads/main/install-firefox-linux/firefox.desktop
mv "firefox.desktop" "firefox${branch}.desktop"

Then, edit the Icon key to match your installation if needed (e.g. /home/duncan/firefox instead of /opt/firefox), and edit the name to your liking. Once you reopen Firefox it should have the correct icon and you'll avoid the first problem.

Once you do have a desktop entry: If the misassignment upsets you, then whenever you make a taskbar tab for the first time, search for the site name in GNOME. Once the result appears, close the taskbar tab and open it again from GNOME. The application should now be set correctly.

Comment 1

[Duncan McIntosh [:dmcintosh]]

ni? me to look into this.

Comment 2

[Duncan McIntosh [:dmcintosh]]

I've submitted a WIP patch to GNOME: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/4175. Likely will be a bit before that is merged, but I'll un-ni? myself in the meantime.

Comment 3

[Bogdan Maris, Desktop Test Engineering]

Attachment: Issue with tar.xz

A consequence of this icon issue is that a user who uses Firefox from a tar.xz can end up having a different Icon (not Firefox icon) for the main browser window (not the tab which was pinned to taskbar). In this case the if the user has pinned one tab and then it closes it, it will not be able to open the tab again in that browsing session since the app will appear that is open even though it is not.

I've attached a video showing the issue. (sorry for the low performance in the video, that specific VM did not work that good)

Let me know if you want me to log a new issue or it will not be necessary since after/when this is fixed I probably not end up in this situation anymore.

Comment 4

[Duncan McIntosh [:dmcintosh]]

That's a known issue I folded into this bug (that's the "doesn't have a desktop file" category), and is the main reason I started looking into who does have / doesn't have desktop entries.

Unfortunately not sure whether we can work around this on the GNOME side, it's a sketchy heuristic but it was probably added for a reason. If this can't be dealt with as part of this bug then I'll fork out a new bug after.

Comment 5

[Duncan McIntosh [:dmcintosh]]

At this point I'm not sure I'll be working on this. It still affects Firefox, so I'll keep it open, but it also affects Chromium's implementation (and has done for the last decade or so), and I think the current stance is approaching 'this is a GNOME bug'.