Bug 119202 - LibreOffice apps should not change their WM_CLASS values after being launched
Summary: LibreOffice apps should not change their WM_CLASS values after being launched
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
6.2.2.2 release
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: KDE
  Show dependency treegraph
 
Reported: 2018-08-10 17:30 UTC by Nate Graham
Modified: 2019-03-30 09:47 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2018-08-10 17:30:08 UTC
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).
Comment 1 Caolán McNamara 2018-09-06 12:47:45 UTC
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
Comment 2 Stefan Zurucker 2019-03-30 09:47:14 UTC
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