Description: This bug affects all LO 6.x apps. It was not present in 5.x. When you launch (for example) LO Writer, it creates a generic window with the class WM_CLASS "libreoffice LibreOffice 6.0". After a moment, it changes the WM_CLASS to "libreoffice libreoffice-writer". This causes issues in KDE Plasma: https://bugs.kde.org/show_bug.cgi?id=396871 Steps to Reproduce: 1. Use KDE Plasma (any recent version) 2. Use an Icons-only task manager 3. Install LibreOffice 6.x 4. Pin LO Writer to your Icons-Only Task Manager and move it so it's not the last pinned icon 5. Click on the LO Writer icon that you've pinned to your Icons-Only Task Manager Actual Results: Because the WM_CLASS value changes, a new icon is created at the end of the list rather than the Task Manager knowing that it's an instance of the pinned app and re-using the pinned app icon. See the video in https://bugs.kde.org/show_bug.cgi?id=396871 (https://drive.google.com/file/d/1_G69tnyXNT_CQPBC8JOCl3LIgL7zyxyB/view?usp=sharing) Expected Results: The WM_CLASS value should not change, which would allow the Task Manager to know that the spawned window is an instance of the pinned app. Reproducible: Always User Profile Reset: Yes Additional Info: The issue could be resolved by having each LO app use the same WM_CLASS value for the generic window as for the actual UI window that the user will interact with. (it would also be solved by doing away with the whole immediately-spwan-a-generic-dummy-window thing entirely but I imagine that's more architecturally complex or else it would have already been done).
With gtk3 under wayland we don't change the WM_CLASS (or equivalent) which gives rise to the issues of bug 100158. See vcl/unx/gtk3/gtk3gtkframe.cxx with the // rhbz#1334915, gnome#779143, tdf#100158 comment so it is possible to survive without changing the WM_CLASS that said we've changed the WM_CLASS for years and years, so "This bug affects all LO 6.x apps. It was not present in 5.x." sounds odd to me wrt the WM_CLASS hackery
I apologize for necroing this thread, but I have to report that the behavior described by Nate appears to be back in version 6.2.2. - this happens with an install from the "Fresh" PPA as well as with the snap version. The bug did not occur for me in 6.1.x, however. Therefore I can only assume that something has been changed in 6.2.2. that triggers it again. Reproducible: Always (tested on two separate machines) LibreOffice: 6.2.2-0ubuntu0.18.04.1~lo1 Operating System: KDE neon 5.15 KDE Plasma Version: 5.15.3 KDE Frameworks Version: 5.56.0 Qt Version: 5.12.0
@Michael Weghorn, do you reproduce this on your end ?
(In reply to Xisco Faulí from comment #3) > @Michael Weghorn, do you reproduce this on your end ? I'm quite sure I tried a while ago but couldn't reproduce easily. As far as I understand, a workaround has been implemented in Plasma, s. this commit: https://cgit.kde.org/plasma-workspace.git/commit/?id=b15eaf38b6bf8d5af7fdc0caff05679a063819cf Therefore, one would probably have to use an older version of Plasma or revert that patch to be able to still reproduce the issue.
Created attachment 151107 [details] LO duplicate icon far right after launch. As a user affected by this issue I've been following this bug report. The issue is still present using: Libreoffice Version: 6.2.3.2 Build ID: 20(Build:2) Operating System: openSUSE Tumbleweed 20190428 KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.57.0 Qt Version: 5.12.3 See attached screenshot. The (normally positioned) pinned icon has the cursor and tool-tip, after LO launches there is a second icon at the far right. This is with the "fixed" version of plasma. It has been an ongoing issue for quite some time.
(In reply to Paul from comment #5) > The (normally positioned) pinned icon has the cursor and tool-tip, after LO > launches there is a second icon at the far right. > > This is with the "fixed" version of plasma. It has been an ongoing issue > for quite some time. Thanks for the update, setting to NEW then.
What is missing in all the comments is the VCL plugin in use (just copy "About LibreOffice"), but I guess it's not kde5. Because for me it's currently just $ SAL_USE_VCLPLUGIN=kde5 soffice --writer $ xprop WM_CLASS WM_CLASS(STRING) = "soffice.bin", "soffice.bin" And that actually never changes. $ SAL_USE_VCLPLUGIN=gtk3 soffice --writer $ xprop WM_CLASS WM_CLASS(STRING) = "libreoffice", "libreoffice-writer" And since gtk3_kde5 is just gtk3 + kde5 file picker as an external app, it's gtk3 from the code => same problem. And I'm not sure anything regarding gtk3 should be fixed. If the user chooses to run the gtk3 backend on KDE, because currently kde5 has much more bugs and problems then gtk3, then the user have cope with that fallout. IMHO we don't want special desktop handling in each backend. BTW: LO has an internal fallback list of plugins so it tries hard to always start up. Always check "About LibreOffice" for the real plugin in use! Even SAL_USE_VCLPLUGIN is just a preference. Now probably we should change the WM_CLASS to libreoffice for kde5? After reading all the stuff / bugs I'm not sure about it. What is the expected behavior here? Should there be different grouping for different LO document types, except the icons in the group list? And I couldn't find any Qt Core function to change the WM_CLASS.
(In reply to Jan-Marek Glogowski from comment #7) > What is missing in all the comments is the VCL plugin in use (just copy > "About LibreOffice"), but I guess it's not kde5. > Version: 6.2.3.2 Build ID: 20(Build:2) CPU threads: 2; OS: Linux 5.1; UI render: default; VCL: kde5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded ... and as I wrote in comment #5 I'm seeing this issue. I don't know if this is relevant, but: On mouseover of the first (i.e. correctly positioned) icon, the tooltip shows "LibreOffice Writer" and over the far right (second icon after LO is lauched), the tooltip shows "soffice.bin"
(In reply to Paul from comment #8) > I don't know if this is relevant, but: > > On mouseover of the first (i.e. correctly positioned) icon, the tooltip > shows "LibreOffice Writer" and over the far right (second icon after LO is > lauched), the tooltip shows "soffice.bin" So actually the first window is wrong and the 2nd correct. What happens with a 3rd window? I guess it'll be correctly grouped with the 2nd. For me with my master build on Debian Buster, the KDE panel shows soffice.bin for all windows in the mouse-over popup and groups them correctly, also verified with "xprop WM_CLASS". But that has really a ton of changed to Qt code. Still there isn't anything I know that might result in a WM_CLASS change. I'm really puzzled. Please try a daily master build: https://dev-builds.libreoffice.org/daily/ More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds What did you do to get the first window? You don't use two profiles, so these would result in independent soffice processes? Still the auto-detection should always use kde5, if it's installed... If you just start the single window, is it also using kde5?
OK... I'm sorry, but you've rather managed to confuse me here :) There is only one instance of LibreOffice and one (LO) window. Within the the (KDE) Icon Only Task Manager I have a "pinned" icon (which on mouseover shows LibreOffice Writer) for Writer. This launches LibreOffice Writer using "/usr/share/applications/writer.desktop" (with the exec line "Exec=libreoffice --writer %U") When Writer launches via that icon, a second icon (mouseover soffice.bin) appears at the far right of the Task Manager.
(In reply to Paul from comment #10) > OK... I'm sorry, but you've rather managed to confuse me here :) Yeah sorry. I'm trying to understand what's going on. My assumption is that grouping just happens on WM_CLASS. The kde5 VCL doesn't set or change it and it's always soffice.bin. > There is only one instance of LibreOffice and one (LO) window. > > Within the the (KDE) Icon Only Task Manager I have a "pinned" icon (which on > mouseover shows LibreOffice Writer) for Writer. > > This launches LibreOffice Writer using > "/usr/share/applications/writer.desktop" (with the exec line > "Exec=libreoffice --writer %U") > > When Writer launches via that icon, a second icon (mouseover soffice.bin) > appears at the far right of the Task Manager. Ok - now I think I understand what's going on. The pinned icon is wrong. This was probably created when starting with gtk3 or gtk3_kde5. It saved that WM_CLASS, which was WMCLASS("libreoffice", "libreoffice-writer"), because gtk3 changes it for some Gnome grouping requirement, so documents are grouped per type (Writer, Calc, etc.) which have normally separate launch icons. As I wrote kde5 doesn't do this (yet). It always reports soffice.bin. So the new LO process won't be grouped with your pinned icon. I don't know if different icons for the same app can be handled correctly. Thing is LO can just change the WM_CLASS based on the document type very late, as document loading is late, so these workarounds are for grouping in KDE are needed. Gtk+ and KDE devs claim to not change the WM_CLASS, but this doesn't match with LO's requirements, which has different "main" modules with icons in the same binary name.
And just to make it clear, I currently don't know if I should consider it a bug that the kde5 backend doesn't adapt the WM_CLASS like gtk3 does. I should probably ask the KDE devs directly, how to handle this best, but I assume there isn't a good solution.
OK... I'm less confused now ;) The pinned icon was indeed added to the Task Manager quite some time ago. If I remove that icon, launch Writer from the Application Menu, then re-pin the icon to the Task Manager, close Writer, and relaunch using the newly pinned icon, there is no second icon. However, it is the LibreOffice Start Centre that now launches, as opposed to launching Writer directly. If I again remove that icon, this time adding it back not by pinning from the launched application but by the "Pin to Task Manager" option from the Application Menu, then I'm back to the initial situation. i.e. Writer launches directly from the Task Manager Icon, with a second icon appearing after launch. As I really want Writer to launch directly from the Task Manager I'll live with the second instance of the icon. It's a "bug" that affects the "look" rather than functionality, it would be good if it was eventually resolved, either at the LO or KDE level. Thanks for your explanation and time, appreciated.
Since this was initially reported for 6.1, it doesn't look specific to the kde5 VCL plugin (which wasn't there in 6.1 yet). [Setting back the bug's "Version" field back to the one initially used, since that field describes the earliest version affected.]
I appreciate that bug trackers are not for general discussion, but would like to add the following. I may be mistaken, but I believe on 6.1 (pre kde5 VCL) the kde workaround mentioned in comment #4 offered a "fix". Certainly for a while this issue was "solved", perhaps it was the introduction of the kde5 VCL that broke kde's workaround? I don't see this as being a straightforward issue to resolve, not only are two sets of developers (kde & LO) involved, but the end users may have differing ideas on the behaviour expected. Personally, I'd like the ability to have individual, per document type, launchers on the Task Manager, for example Writer and Calc, and for grouping to be done by document type. Which if I've understood comment #11 is the behaviour when using Gnome. Other users may of course have differing expectations. KDE and LibreOffice always was problematic with regard to the Task Manager. Pre plasma 5, the Icon Only Task Manager of (KDE) 4.x had the ability to define Launcher Matching Rules, which overcame the problem. I did enquire about it last year ( https://bugs.kde.org/show_bug.cgi?id=398013#c6 ) but the response was not particularly favourable. I will follow this report with interest, but will make no further comment. My thanks to all developers involved.
This is a adapted copy from my brain dump at https://gerrit.libreoffice.org/#/c/74014 (a potential fix), with my current understanding the problem. Normally you have a binary and then multiple "one icon : one WM_CLASS string : one window". That association isn't supposed to change, so the Gtk and KDE developers think / say. If the window is created, it's WM_CLASS metadata shouldn't change (and I guess the icon too?). That's the (paraphrased) title of this bug after all. Now LO has a problem: 1. LO just has one binary but separate icons and brand names for it's modules 2. The loaded document type may change the icon and name / WM_CLASS of the window So the window manager developers assumption of the fixed "one icon + one WM_CLASS string + one window" is broken by LO. Maybe there is some definition / agreement not to do this, but fact is it is allowed by the protocol. It's not that LO is somehow circumventing anything. One suggestion was to change LO to destroy / recreate the window on document / brand change, but that is expensive and would be really disturbing for a user. The first thing that breaks now is the grouping, based on WM_CLASS in general. The 2nd thing the pinning of applications, like Pauls problem. That is actually not easily fixable, as the originally started program, e.g. Writer, might later be an Impress window when pinned. The content always sets name and icon (just imagine --writer as an empty writer document). Actually it's kind of fixable, like tdf#100158 did, because you can change the program parameters and names at runtime too. Heck we do this in the qt5 backend when we create our QApplication, because we have to prevent Qt's own session management, as LO handles this itself. And the current patch maybe also isn't a complete fix. gtk3 also changes the WM_CLASS (and should do the same for the icons IMHO) for all child windows. AFAIK the best solution would be to set WM_CLASS, keep the program name but change the parameter. But that would be even more unexpected and I don't think it would work with current WM implementations. And OTOH tdf#100158 changes the application name to the icon name to match grouping on Wayland :-) I'm not sure yet, that there is an always working solution, but can imagine a best effort one. I know LO requirements are very uncommon here, but than it's nothing changeable without a massive rewrite how LO is working; not feasible; not even taking any "improvement" vs "time spend" into account.
(In reply to Paul from comment #15) > I may be mistaken, but I believe on 6.1 (pre kde5 VCL) the kde workaround > mentioned in comment #4 offered a "fix". Certainly for a while this issue > was "solved", perhaps it was the introduction of the kde5 VCL that broke > kde's workaround? Reading the commit message of the kde workaround again, that sounds plausible, and the Gerrit change should actually fix the issue in this case, as far as I understand. > I will follow this report with interest, but will make no further comment. > My thanks to all developers involved. No need to be silent, comments are appreciated. :-)
A "fun" fact is, that LO's kde5 backend now does what the original bug report is about, so the bug actually can be considered fixed. And Paul's problem is a regression of this "fix" and should be an additional bug. And the kde4 backend in LO 5.x didn't set WM_CLASS AFAIK. This started with gtk3_kde5, so Nate is correct. What a mess.
Yes, the original bug was about gtk3_kde5. Sorry for omitting that important piece of information! However happily I can confirm that the problem is gone with the kde5 VCL as of LO 6.2.4.2.0.
Filed a follow-up bug for the remaining issues seen when using the kde5 VCL: https://bugs.documentfoundation.org/show_bug.cgi?id=125921