Description: I can't tell if this might just be a bug in Debian, but opening any window inside a LO instance, be it settings, extension manager, cross-reference manager etc. it's impossible to move that window. E.g., if you have Writer maximized and open settings, if you try to only move the settings popup window, the whole instance is moved. So the writer window is no longer maximized and moves around relative to the settings window. While that might not be that big of a problem with the settings window, it is a very big problem, e.g., with the cross-reference manager or the chart wizard. Also it's quite unlikely that either the GTK packages from Debian Testing or the LO version they compile is to blame, since the same happens with the flatpak version, which should be distribution independent. Also I can't tell if that's related, but having multiple pop-up windows open interferes with the ability to have the correct window on top. So if you open a pop-up window from a pop-up window, with every pop-up window blocking entry to the previous one, it happens that the window that should be on top isn't on top when you switch to any other program and come back via the Gnome window switcher. So you need to find the right window in the "switch system controls" shortcut to bring it back to the front. Steps to Reproduce: 1. open any of the suite's programs 2. open a pop-up window inside 3. try to only move that pop-up window Actual Results: The whole instance is moving, so you can't uncover what's covered by the pop-up window Expected Results: Any sub-window of an instance should be able to move independently. Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: de-DE (en_US.UTF-8); UI: de-DE Debian package version: 4:7.6.4~rc1-1 Calc: threaded Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Flatpak Calc: threaded
Suppl.: installing libreoffice-gtk4 and removing libreoffice-gtk3 does help with that, though the UI of the GTK4 port seems to be still very bare bone and not ready to be used. Also it seems to be using X11, not Wayland, so using fractional scaling with it wouldn't be an option. Question is how long the GTK4 port takes to be ready to replace the GTK3 port. If that's around the corner there might not be a need to fix this bug. But it doesn't really look like it, so it would be preferable if this could be fixed before that.
I can't reproduce it in openSUSE Tumbleweed with Plasma (former KDE). Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: 60(Build:1) CPU threads: 16; OS: Linux 6.6; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: es-ES Calc: threaded
That means it's only happening with the GTK based version, as both the default version Debian ships and the one you'll get from Flatpak are based on it. BTW: have you tried the Flatpak version?
Hello, this is related to GTK3 and I can confirm it. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 71c28942fbc7f36e5bcd46c5a6cdfbb3fcbcd6a0 CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
This isn't specific to LibreOffice (assuming is it the commonly reported thing that sounds like this) and can be controlled at a general desktop level with gnome-tweaks where you can untick "Windows, Attach Modal Dialogs" to disable this feature (that is out of the control of the application).
Thanks, that did solve the issue. Problem solved.