1770636 - Wrong StartupWMClass in .desktop file of the flatpak version

Status: VERIFIED FIXED

(Core :: Widget: Gtk, defect)

Description

[soljanka]

Attachment: 2nd Firefox icon after launch in plank

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

Steps to reproduce:

In bug 1640153 the StartupWMClass was added to the .desktop file for flatpak to prevent instances not shown with the same icon. The following line was added to the file:

StartupWMClass=Firefox

Unfortunately this is case sensitiv. xprop WM_CLASS returns the following
WM_CLASS(STRING) = "Navigator", "firefox"

Actual results:

This results in Firefox still launching with a second icon as seen in the attached screenshot.

Expected results:

The solution is quite simple. Change StartupWMClass=Firefox to StartupWMClass=firefox with a lowercase f and Firefox will launch with the same Icon.

Comment 1

[soljanka]

Attachment: Firefox launching with the same icon after changing StartupWMClass manually in the .desktop file

Comment 2

[Darkspirit]

https://searchfox.org/mozilla-central/rev/fb319b5522a5e9fc126a9b2d2650aa49cc88e40a/taskcluster/docker/firefox-flatpak/org.mozilla.firefox.desktop#54 needs to be changed to lowercase.

(Emilio Cobos Álvarez (:emilio) from bug 1759663 comment 4)

Yeah, so this changed in bug 1530052. It was kind of an intentional change to make WMClass and wayland app id consistent.

Comment 3

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

Set release status flags based on info from the regressing bug 1530052

Comment 4

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

:heftig, since you are the author of the regressor, bug 1530052, could you take a look?
For more information, please visit auto_nag documentation.

Comment 5

[Jan Alexander Steffens [:heftig]]

I think this is similar to bug 1759663, and if we let the window class start with a capital letter (by removing our override and just setting the prog name) this bug would be fixed as well.

That is, assuming that Wayland tools consistently compare the strings case-insensitively where X11 tools like plank do not.

Comment 6

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Comment 7

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

Set release status flags based on info from the regressing bug 1530052

Comment 8

[Pascal Chevrel:pascalc]

emilio, is that something you know about? Thanks

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1770636 - Fix StartupWMClass of flatpak package to match actually-used WMClass. r=jhorak,stransky

Pending further changes iff we want to do them (like comment 5), this is the
right thing to do.

I'm not a fan of comment 5 since in the past I've been bitten by Wayland
compositors not comparing stuff case-insensitively, so making everything
lowercase is probably simpler.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/8bc2a43e9ac0
Fix StartupWMClass of flatpak package to match actually-used WMClass. r=jhorak

Comment 11

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/8bc2a43e9ac0

Comment 12

[Pascal Chevrel:pascalc]

Emilio, is that something we could want in a 102 dot release and ESR102? Thanks

Comment 13

[Emilio Cobos Álvarez (:emilio)]

I don't know if we do flatpack ESR releases and how we build them. Do you know?

If we do and use the flatpack script from the tree then sure, it's harmless.

Comment 14

[Pascal Chevrel:pascalc]

I don't know either but given that it is just a typo fix, it feels safe to just uplift it to the release and esr102 branches.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

Comment on attachment 9282247 [details]
Bug 1770636 - Fix StartupWMClass of flatpak package to match actually-used WMClass. r=jhorak,stransky

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Trivial one-liner fix to Flatpak desktop file.
• User impact if declined: comment 0
• Fix Landed on Version: 103
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple lowercasing of the WMClass.

Beta/Release Uplift Approval Request

• User impact if declined: see above.
• Is this code covered by automated tests?: Unknown
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): see above
• String changes made/needed: none
• Is Android affected?: No

Comment 16

[Pascal Chevrel:pascalc]

Comment on attachment 9282247 [details]
Bug 1770636 - Fix StartupWMClass of flatpak package to match actually-used WMClass. r=jhorak,stransky

Approved for 102.0.1, thanks.

Comment 17

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-release/rev/3b2fd7431696

Comment 18

[Cristian Baica [:cbaica], Release Desktop QA]

Issue was reproduced using Firefox 101.
The issue is verified fixed using the latest Fx 103.0b5. The typo in the .desktop file is now fixed and correctly written as 'firefox'. Please note that the 102.0.1 can't be verified as the published build on flathub beta is the 103.0b5 build.

Comment 19

[Donal Meehan [:dmeehan]]

Comment on attachment 9282247 [details]
Bug 1770636 - Fix StartupWMClass of flatpak package to match actually-used WMClass. r=jhorak,stransky

Approved for 102.1esr.

Comment 20

[Donal Meehan [:dmeehan]]

https://hg.mozilla.org/releases/mozilla-esr102/rev/eaa10c8a0489

Comment 21

[Pascal Chevrel:pascalc]

https://hg.mozilla.org/releases/mozilla-esr102/rev/ae8433beaa5d230836bc08249cd5a1b900fd806f FIREFOX_ESR_102_0_X_RELBRANCH