Bug 155448 - Window does not unmaximize (normalize) when first opened in maximized state on GNOME-Wayland
Summary: Window does not unmaximize (normalize) when first opened in maximized state o...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
7.5.3.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Wayland GTK3
  Show dependency treegraph
 
Reported: 2023-05-23 11:47 UTC by Nolan Leasy
Modified: 2025-11-01 18:32 UTC (History)
2 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 Nolan Leasy 2023-05-23 11:47:13 UTC
Description:
When a LibreOffice window was in the maximized state on last close, it correctly opens in a maximized state. However, it will not unmaximize (normalize) before (a) first sending an initial unmaximize message, (b) sending another maximize message and finally (c) sending a 2nd unmaximize message.

You get this behavior whether using a mouse double-click or keyboard shortcuts. If using the double-click method, it will require 3 double-clicks to unmaximize the window.

A left or right tile action also frees the window to be unmaximized (normalized).

An attempt to drag the window down, from maximized, presents the user with a window that is mostly off the screen.

Steps to Reproduce:
1. Maximize an open LibreOffice window and close it.

2. Re-open the same LibreOffice componenent (Calc, Writer or Impress), which will correctly open in the maximized state.

3. Attempt to unmaximize the window, which will produce a flicker as the window fails to unmaximize.

4. Attempt to maximize the window, which will leave it in the same maximized state. At this point the window can be unmaximized normally.

5. Unmaximize the window normally.

Actual Results:
The window will not unmaximize on first attempt.

Expected Results:
The window should unmaximize on first attempt.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
- This only affects freshly opened maximized windows. Once past this bug with the same instance, the same window maximizes and unmaximizes normally.

- The 'libreoffice-x11' package is installed.

- This seems to be a problem only with GNOME Wayland Sessions. I did NOT see this on GNOME Xorg/x11 or on KDE Wayland.

- I have reproduced this behavior on GNOME Wayland sessions in both the Fedora and openSUSE environments.

- The versions of LibreOffice used were all from the standard Fedora and openSUSE repositories.

- All recent versions are affected from what I can tell. I have reproduced the bug with Ver 7.4.6 and Ver 7.5.3.
Comment 1 Nolan Leasy 2023-05-23 12:08:16 UTC
- This is on GNOME (Wayland) version 43.
Comment 2 Nolan Leasy 2023-05-23 18:24:44 UTC
I can confirm that this is also a problem with LibreOffice 7.4.3 on GNOME 41.9 (Wayland). This was on openSUSE Leap 15.x and there is no 'libreoffice-x11' package installed.

Again, this problem does NOT present on any version of GNOME running an Xorg/x11 session. Only on Wayland.
Comment 3 Nolan Leasy 2023-07-24 20:03:16 UTC
Has anyone taken a look at this problem?

Does anyone care about this anomalous behavior?
Comment 4 Buovjaga 2023-11-01 18:43:02 UTC
Reproduced, used the method of double-clicking the title bar as there were no window controls. LibreOffice 7.6.2 gtk3, Debian 12, GNOME with Wayland.
Comment 5 QA Administrators 2025-11-01 03:12:49 UTC Comment hidden (obsolete)
Comment 6 Nolan Leasy 2025-11-01 18:32:44 UTC
This bug is still present in LibreOffice 25.8.2.2, running on openSUSE Tumbleweed GNOME 49.1 Wayland, using their standard Mutter compositor.

=> About LibreOffice:

Version: 25.8.2.2 (X86_64) / LibreOffice Community
Build ID: 580(Build:2)
CPU threads: 4; OS: Linux 6.17; UI render: default; VCL: gtk3
Locale: en-US (en_US.utf8); UI: en-US
Calc: threaded


=> OS Release
cat /etc/os-release 
NAME="openSUSE Tumbleweed"
# VERSION="20251018"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20251018"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
# CPE 2.3 format, boo#1217921
CPE_NAME="cpe:2.3:o:opensuse:tumbleweed:20251018:*:*:*:*:*:*:*"
#CPE 2.2 format
#CPE_NAME="cpe:/o:opensuse:tumbleweed:20251018"
BUG_REPORT_URL="https://bugzilla.opensuse.org"
SUPPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo-Tumbleweed"


=> GNOME Version

gnome-shell --version
GNOME Shell 49.1


=> Wayland

env | grep XDG_SESSION_TYPE
XDG_SESSION_TYPE=wayland


=> Additional Notes

- The Firefox browser used to exhibit exactly the same misbehavior on GNOME Wayland, but they have since resolved their issue. Whatever they did to fix their bug might be the answer to yours as well.

- This behavior is NOT present on KDE Plasma 6.4 using their standard KWin compositor on Wayland.

- I was unable to get the old version of OpenOffice (ver 3.3) running in my environment, due to Java Runtime issues that I was unable to resolve. However, this bug is probably a simple case of no one having the time to deal with window management issues in the GNOME Wayland environment.