Closed Bug 1607399 Opened 5 years ago Closed 3 years ago

Firefox Wayland not associating icon and title to windows

Categories

(Core :: Widget: Gtk, defect, P3)

72 Branch
defect

Tracking

()

RESOLVED DUPLICATE of bug 1530052

People

(Reporter: kylerferriter, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

Attached file firefox-beta.desktop (deleted) —

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.88 Safari/537.36

Steps to reproduce:

  1. Using GNOME Wayland (3.34.2) on Fedora 31.

  2. Do not have any distro/flatpak/snap package for firefox installed.

  3. Download the Firefox tar archive from https://www.mozilla.org/en-US/firefox/channel/desktop/ and unarchive.

  4. From this unarchived directory, launch Firefox 72 in X11 window mode with "./firefox".
    (RESULT 1)

  5. Quit Firefox

  6. Launch Firefox again, but in Wayland window mode with "MOZ_ENABLE_WAYLAND=1 ./firefox"
    (RESULT 2)

  7. Repeat but with a file firefox-beta.desktop in ~/.local/share/applications/ specifying an Icon, and Name "Firefox Beta".
    (RESULT 3)

Actual results:

RESULT 1:
Shell window menu with Firefox in regular X11 mode: https://i.imgur.com/LdMvZDu.png
Window switcher with Firefox X11 mode: https://i.imgur.com/YZDjlsM.png

RESULT 2:
Shell window menu with Firefox in wayland mode: https://i.imgur.com/NbJS8Fr.png
Window switcher with Firefox wayland mode: https://i.imgur.com/9IbU0ad.png

RESULT 3:
No change from RESULT 1 and 2 for X11 and Wayland modes respectively.

Expected results:

In X11 mode, the proper icon and title ("Firefox") are associated with window instances from this application.
In Wayland mode, no icon is associated, and the wmclass title "firefox" is associated with the window instead of the properly capitalized title "Firefox".

Adding a .desktop file named "firefox-beta.desktop" and launching that from the GNOME Shell launcher did not resolve the issue. Using a .desktop file with Name (title) and Icon values to launch in Wayland mode still did not associate the Title and Icon from the .desktop file to the Firefox window. (see firefox-beta.desktop attached)

Workarounds discovered:

  • If option --name firefox-beta is passed to firefox command, then firefox-beta.desktop is picked up from ~/.local/share/applications/firefox-beta.desktop. And its values are associated with the window. This workaround again works for Wayland mode and X11 mode. In Wayland mode it provides a title and icon in the first place, and in X11 mode it updates the default "Firefox" title and icon to those specified in the firefox-beta.desktop file.
  • If the distro package for Firefox is installed (dnf install firefox), then without a --name option passed, an Icon and Title are set from the file installed at /usr/share/applications/firefox.desktop due to the default Firefox Wayland wmclass of "firefox". The Wayland Firefox window is associated with this file, and this results in a mismatch if the Name or Icon from the intended ~/.local/share/applications/ is different (like name "Firefox Beta", while the system file is "Firefox") .
  • If the desktop file is renamed to "firefox.desktop", then Firefox launched in Wayland mode does associate with that file (due to wmclass "firefox") and receive the proper title and icon. This is undesirable because it conflicts if multiple firefox versions are used in this manner and a different .desktop file is needed for each.

Other note:

  • Related Red Hat bug report (but is unrelated to RHEL itself): https://bugzilla.redhat.com/show_bug.cgi?id=1585369. Closed as resolved in Firefox 60 but does not appear to be resolved. StartupWMClass has no effect in desktop file for Firefox Wayland 72.
  • Firefox Nightly in X11 mode sets its wmclass to "Nightly" and receives the title "Nightly" and an appropriate icon, but in Wayland mode sets the default wmclass to "firefox" and receives title "firefox" and no icon.
  • Firefox Beta in X11 mode sets its wmclass to "Firefox" and receives the title "Firefox" and icon, but in Wayland mode sets the default wmclass to "firefox" and receives title "firefox" and no icon. Personal preference perhaps, but I believe Firefox Beta in even in X11 should be titled "Firefox Beta" by default, because it is a different version, like how Firefox Nightly in X11 is titled "Nightly". This would further help avoid improper window grouping by window managers.

Desired changes:
(1) Firefox Wayland should set its default wmclass to something unique for Beta and Nightly, not just "firefox". To match other wmclass conventions and match desktop file conventions, "firefox-beta" and "firefox-nightly" respectively. (Again in addition to helping this issue, it would also help avoid improper window grouping, or mutual exclusion between being able to run Firefox, Firefox Beta, and Firefox Nightly instances as in the Red Hat bug 1585369).
(2) Firefox X11 appears to set an initial sane default value for the icon and title of its windows (I'm not sure how), even if no .desktop file is later associated by the window manager. If possible, Firefox Wayland should do the same.

Blocks: wayland
Status: UNCONFIRMED → NEW
Component: Untriaged → Widget: Gtk
Ever confirmed: true
Product: Firefox → Core

Bug 1530052 is a related problem. Arch is currently carrying a patch (the combination of two patches from Debian) in order to consistently use the remoting name.

It also uses "firefoxnightly" as the remoting name for the Nightly package (the dash is missing because it causes problems with the DBus remoting).

Priority: -- → P3

Wayland behaviour should now match X11s more closely after bug 726479

Posting here since it's not obvious from the issue description how it can be fixed by users having running into this.

Bug 726479 didn't fix this for me (using Nightly on Arch Linux / Gnome Wayland), so I kept my old workaround of editing the .desktop file that Nightly creates under ~/.local/share/applications/ and adding

StartupWMClass=firefox
Icon=firefox-nightly

Should be a duplicate of bug 1530052

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: