Wrong StartupWMClass in .desktop file of the flatpak version
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: soljanka, Assigned: emilio)
References
(Blocks 1 open bug, Regression)
Details
(Keywords: regression)
Attachments
(3 files)
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
text/x-phabricator-request
|
pascalc
:
approval-mozilla-release+
dmeehan
:
approval-mozilla-esr102+
|
Details |
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 2•2 years ago
|
||
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•2 years ago
|
||
Set release status flags based on info from the regressing bug 1530052
Comment 4•2 years ago
|
||
:heftig, since you are the author of the regressor, bug 1530052, could you take a look?
For more information, please visit auto_nag documentation.
Updated•2 years ago
|
Comment 5•2 years ago
|
||
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.
Updated•2 years ago
|
Comment 6•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Comment 7•2 years ago
|
||
Set release status flags based on info from the regressing bug 1530052
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 9•2 years ago
|
||
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•2 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/8bc2a43e9ac0 Fix StartupWMClass of flatpak package to match actually-used WMClass. r=jhorak
Comment 11•2 years ago
|
||
bugherder |
Updated•2 years ago
|
Updated•2 years ago
|
Comment 12•2 years ago
|
||
Emilio, is that something we could want in a 102 dot release and ESR102? Thanks
Assignee | ||
Comment 13•2 years ago
|
||
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•2 years ago
|
||
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.
Assignee | ||
Comment 15•2 years ago
|
||
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•2 years ago
|
||
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•2 years ago
|
||
bugherder uplift |
Comment 18•2 years ago
|
||
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•2 years ago
|
||
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•2 years ago
|
||
bugherder uplift |
Comment 21•2 years ago
|
||
https://hg.mozilla.org/releases/mozilla-esr102/rev/ae8433beaa5d230836bc08249cd5a1b900fd806f FIREFOX_ESR_102_0_X_RELBRANCH
Description
•