[Libreoffice-bugs] [Bug 141106] New: changing WM_CLASS is in conflict with ICCCM standard

bugzilla-daemon at bugs.documentfoundation.org bugzilla-daemon at bugs.documentfoundation.org
Fri Mar 19 10:05:29 UTC 2021


https://bugs.documentfoundation.org/show_bug.cgi?id=141106

            Bug ID: 141106
           Summary: changing WM_CLASS is in conflict with ICCCM standard
           Product: LibreOffice
           Version: 6.4.5.2 release
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: UNCONFIRMED
          Severity: normal
          Priority: medium
         Component: Writer
          Assignee: libreoffice-bugs at lists.freedesktop.org
          Reporter: batpul at gmail.com

Description:
libreoffice writer "Version: 6.4.5.2 Build ID: 40(Build:2)"
when it opens its window has WM_CLASS property soffice.Soffice and
this is what the window manager sees when it requests to become mapped.
However, soon after it changes it to libreoffice.libreoffice-writer.
This is confusing the window manager which use the WM_CLASS
property to obtain configuration resources. It is also in conflict
with the ICCCM standard, which states in section 4.1.2.5:

"This property must be present when the window leaves the
Withdrawn state and may be changed only while the window
is in the Withdrawn state. Window managers may examine
the property only when they start up and when the window
leaves the Withdrawn state, but there should be no need
for a client to change its state dynamically."

On top of that, the new values of the res_name and res_class
fields of the XClassHint appear to be swapped.

My complaint is therefore that libreoffice is in conflict
with the ICCCM, and therefore also with the EWMH standard.
It is also confusing with the way some standards conforming
window managers are designed to work.
My request to libreoffice is therefore to do respect the
standards and to only change its WM_CLASS property when
still in the Withdrawn state.

Steps to Reproduce:
1. start libreoffice writer
2.
3.

Actual Results:
changing WM_CLASS when already mapped, which isn't allowed, and is confusing.

Expected Results:
be social and easy to work with and therefore be standards conformant.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Set the proper value of WM_CLASS before mapping the window and never change it!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210319/1894f214/attachment.htm>


More information about the Libreoffice-bugs mailing list