Possibly related to bug #150236 and similars. Problem: given some specific conditions, opening an existing (or new) document will result in a mis-sized screen, in which the status bar is not be visible. Simplest steps to reproduce: - start with --safe-mode command-line argument - when asked, click "continue in safe mode" - once the start center is visible, maximize the window - create a new calc document (procedure also works with Writer document) - on the bottom, notice that the status bar (i.e. the line indicating the zoom level) is visible, as well as the tab list - close the document - create a new one - on the bottom, notice that the tab list is visible, but that the status bar is not - possibly hidden by the OS's taskbar - from this point, all documents created or opened will not show the status bar - de-maximizing and re-maximizing the window resolves the issue... but it's annoying. Additional notes - bibisected on the "relases" version to 7.4.0.0.beta1 - see log below - only reproduced on one specific machine, which runs Debian/KDE. Not reproduced on Windows 10 on the same computer - only reproduced on the laptop's built-in 1366x768 screen. Not reproduced when the same computer is connected to an external 2560x1440 display. - I can bibisect it on the 7.4.0 tree later this week if it helps, but given the changes that were done to fix #150236, I suspect that it might not be worthwhile. Let me know. - I'm assuming that --safe-mode eliminates all possible configuration issues. Let me know if I'm missing something. Thanks. # bad: [f74cdf1695a86287473f938714d5634d5aa263be] libreoffice-7.4.7.2 # good: [2770c66a6f192f50ab95369500f9aa173b9feb6e] libreoffice-7.2.0.2 git bisect start 'f74cdf169' '2770c66a6' # good: [27f3ae17bc2accdecccc669b29cdd0f76b18a621] libreoffice-7.3.3.2 git bisect good 27f3ae17bc2accdecccc669b29cdd0f76b18a621 # bad: [454d6018ad36e040bfa38e15a11abebaf37f09f2] libreoffice-7.4.0.3 git bisect bad 454d6018ad36e040bfa38e15a11abebaf37f09f2 # good: [a97b011777104b40d94bba98771b7534af453b96] libreoffice-7.3.6.2 git bisect good a97b011777104b40d94bba98771b7534af453b96 # good: [ecd3442e06c86e68a30e733be8480477ad128b0e] libreoffice-7.4.0.0.alpha1 git bisect good ecd3442e06c86e68a30e733be8480477ad128b0e # bad: [c193b6c5f4ca36c29b8fac56db586600c59d3acc] libreoffice-7.4.0.1 git bisect bad c193b6c5f4ca36c29b8fac56db586600c59d3acc # bad: [07e204c86738205a6225f6277f26a739611bf885] libreoffice-7.4.0.0.beta1 git bisect bad 07e204c86738205a6225f6277f26a739611bf885 # first bad commit: [07e204c86738205a6225f6277f26a739611bf885] libreoffice-7.4.0.0.beta1
bibisected in the 7.4 tree. 23f33d64739e63a5f5441f05a432cc3783f25cee is the first bad commit commit 23f33d64739e63a5f5441f05a432cc3783f25cee Author: Jenkins Build User <tdf@pollux.tdf> Date: Sat May 28 15:43:04 2022 +0200 source 9ea767cb568cef1b142190d2adb0e301baa382e2 source 9ea767cb568cef1b142190d2adb0e301baa382e2 instdir/program/libvclplug_qt5lo.so | Bin 2301048 -> 2307528 bytes instdir/program/setuprc | 2 +- instdir/program/versionrc | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-) # bad: [fe8a03537f5dbfe6a21a970ff59db81d757ff243] source f8ba7c6f77497e2dc7bfef8378511e2074ce01f9 # good: [36b1ce7e6118699fd36c37261da7f24f935b41ac] source 229123ccc6f90ebf66b3e659bebbd53f8a9bdd3a git bisect start 'origin/master' 'oldest' # good: [d9e7ea2e6ef000b242efcf6e5a18263d13f7c8ae] source 10981fb2fa26474f432e85165b1babbca6d74e16 git bisect good d9e7ea2e6ef000b242efcf6e5a18263d13f7c8ae # good: [d57ef7c663977f6ed623357fae7b8aa0f5d4442d] source 4743a32b4f991c57e4b8a66adf035b1808ca793a git bisect good d57ef7c663977f6ed623357fae7b8aa0f5d4442d # bad: [9132e1d0765ef7cd3ff2622e5d60ea7b1f2f1d5c] source 11a5a54567da8e85673aa48740ce7af08cba6016 git bisect bad 9132e1d0765ef7cd3ff2622e5d60ea7b1f2f1d5c # bad: [a68325e8a705df76c053ad9db2aeccc4f3ef7246] source 147da063241fce62f623bba61feead879be87beb git bisect bad a68325e8a705df76c053ad9db2aeccc4f3ef7246 # good: [02a046143f9ce030521dc1bdc1093d65b21d72de] source 7fffe8bfdc6c5c4034700d16c996c112ec5da400 git bisect good 02a046143f9ce030521dc1bdc1093d65b21d72de # bad: [d8321a512b303ea0a0a52730823887107e1cea0a] source f0c82758f814c58f65e8cfb54bf01a97b1d73261 git bisect bad d8321a512b303ea0a0a52730823887107e1cea0a # good: [ee3c4314eccdffc255d85162b07e3a80798eaf30] source 73696a01224a3758bde686f32ec7e6f4c90877fe git bisect good ee3c4314eccdffc255d85162b07e3a80798eaf30 # good: [05b7823bf55961d1ba6cc42ba150b13551d40501] source 553750d5763b2e605cc8990d81c5588db4319b62 git bisect good 05b7823bf55961d1ba6cc42ba150b13551d40501 # bad: [9eefcf53964fa80aeae3b86592fa23d0666809c6] source 8ec7b04808b8aca32e2c38b8042af9b3c9bbe071 git bisect bad 9eefcf53964fa80aeae3b86592fa23d0666809c6 # bad: [cbd72d665ac9b84f0e7b197f53f56a251ed0263b] source 51f46ddaccd9a2c16b6a4a80b7627af7b13850f4 git bisect bad cbd72d665ac9b84f0e7b197f53f56a251ed0263b # bad: [a45671d5f84dc082a73adf9b3512d9c095310335] source 54f6599a4de738dfe3a26e8229e5588d26dd8165 git bisect bad a45671d5f84dc082a73adf9b3512d9c095310335 # bad: [9b43d810f2c603b03f68c398956563d71544d39a] source 87a932120d5f146933ed3bcc16c0f47dab90fd4b git bisect bad 9b43d810f2c603b03f68c398956563d71544d39a # bad: [23f33d64739e63a5f5441f05a432cc3783f25cee] source 9ea767cb568cef1b142190d2adb0e301baa382e2 git bisect bad 23f33d64739e63a5f5441f05a432cc3783f25cee # first bad commit: [23f33d64739e63a5f5441f05a432cc3783f25cee] source 9ea767cb568cef1b142190d2adb0e301baa382e2
(In reply to jeanmarcranger from comment #1) > bibisected in the 7.4 tree. > 23f33d64739e63a5f5441f05a432cc3783f25cee is the first bad commit > commit 23f33d64739e63a5f5441f05a432cc3783f25cee > Author: Jenkins Build User <tdf@pollux.tdf> > Date: Sat May 28 15:43:04 2022 +0200 > > source 9ea767cb568cef1b142190d2adb0e301baa382e2 > > source 9ea767cb568cef1b142190d2adb0e301baa382e2 That is tdf#132350 Qt implement SalMenu button interface I guess it's plausible. I'm not seeing the problem, though. Do you still see this with 24.8? Set to NEEDINFO. Change back to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away. Arch Linux 64-bit Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 960db01dbfe2f916b91782da03532fae1f836445 CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded Built on 29 December 2024
Re-tested on Linux only, with the libreoffice version currently in Debian Backports (24.8), on the same computer that originally had the issue. I'm unable to reproduce it in Plasma/Wayland mode: Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-CA (en_CA.UTF-8); UI: en-US Debian package version: 4:24.8.3-1~bpo12+1 Calc: threaded However, I'm able to reproduce it in Plasma/X11 mode: Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-CA (en_CA.UTF-8); UI: en-US Debian package version: 4:24.8.3-1~bpo12+1 Calc: threaded In this mode: - The steps to reproduce are still accurate, except that the first document is now affected as well - The workaround of de-maximizing/re-maximizing still works - Bug is still only present when using the laptop internal screen
I can't reproduce this on Debian testing in a self-compiled Plasma Dev session, neither with kf5 and the exact version that comment 1 bibisected to, nor with current master and qt6. commit a499874d9c0685d79b629b4bb246394b6b15691a Author: Michael Weghorn Date: Thu Sep 26 18:22:12 2024 +0200 tdf#160837 qt: Rely on toolkit for frame positions, drop menubar hack contained in the current development version and upcoming version 25.2 *might* have replaced handling that might have been related (manual calculation of positions and a hack related to menu bars instead of relying on Qt), see also tdf#160837, but it's hard to tell without being able to reproduce the issue myself. Do you still see the problem in a current daily build? https://wiki.documentfoundation.org/QA/Testing_Daily_Builds Version: 7.4.0.0.alpha1+ / LibreOffice Community Build ID: 9ea767cb568cef1b142190d2adb0e301baa382e2 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 61cb7921a09cffb4f95b36985ecd8acc083b8138 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Thanks for investigating it. Unfortunately, still reproducible with this build: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b3f3d1ffeca42cbe6028f81b5a07c342f84e8c88 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded - Still on the same computer, although on a different disk, still with Debian stable (12.8) + KDE, fully updated as of today, with the Debian libreoffice* packages uninstalled - Started with libreofficedev25.8 --safe-mode - Still with the original procedure, although with the same change reported in comment 3: the initial opening is now also affected - Still only in Plasma/X11, and not in Plasma/Wayland I understand the difficulties of debugging something unreproducible. And to be fair, this isn't one that really bugs me these days - I'm on Wayland more often than not. Still, I'll assist as much as I can.
(In reply to jeanmarcranger from comment #5) > I understand the difficulties of debugging something unreproducible. And to > be fair, this isn't one that really bugs me these days - I'm on Wayland more > often than not. Still, I'll assist as much as I can. Thanks. I just tried in a Debian 12 VM, in a Plasma X11 session with the LO version provided by Debian, but cannot even reproduce there, so am running out of ideas on what else to do. Version: 7.4.7.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-GB Debian package version: 4:7.4.7-1+deb12u5 Calc: threaded