Description: If I fully maximize an LO app window and close it, then open it again, I get a window that appears to be zero-size. Steps to Reproduce: 1. Open LO app (e.g. Calc) and maximize window. 2. Close window. 3. Open the same LO app again. Actual Results: Zero-size window. Expected Results: Maximized window. Reproducible: Always User Profile Reset: Yes Additional Info: Worked fine on earlier versions.
Following items are found in registrymodifications.xcu that might be relevant: <item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.frame.StartModule']"><prop oor:name="ooSetupFactoryWindowAttributes" oor:op="fuse"><value>22,246322648,22,-9352;5;0,0,0,0;</value></prop></item> <item oor:path="/org.openoffice.Setup/Office/Factories/org.openoffice.Setup:Factory['com.sun.star.sheet.SpreadsheetDocument']"><prop oor:name="ooSetupFactoryWindowAttributes" oor:op="fuse"><value>22,248209816,22,-9304;5;0,0,0,0;</value></prop></item> Example of zero-size window seen: https://forums.freebsd.org/attachments/1669333731907-png.15113/
Hi Maxim Did that start recently or did you reproduce with earlier versions? I think it might be a duplicate of either Bug 125543 or Bug 104371, which would both be solved by fixing Bug 97894.
It started only after the recent upgrade to the 7.4.2.3 release, along with the upgrade of the X server, Xfce and other apps on the system. This was triggered by FreeBSD "pkg upgrade", i.e. upgrade of all packages.
Please copy and paste here the contents of your Help - About by clicking the copy button. This allows us to know more about your system.
Version: 7.4.2.3 / LibreOffice Community Build ID: 40(Build:3) CPU threads: 4; OS: FreeBSD 13.1; UI render: default; VCL: qt5 (cairo+xcb) Locale: en-US (C.UTF-8); UI: en-US Calc: threaded
I see you use the qt5 as the UI, which is experimental by itself. What if you launch from the command line with SAL_USE_VCLPLUGIN=gen libreoffice
Works fine with SAL_USE_VCLPLUGIN=gen. It uses Qt5 by default from FreeBSD repo. Thank you very much!
Yeah, that is not a good choice by the FreeBSD packagers. Better would be kf5.
I couldn't reproduce with QT5: Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: qt5 (qfont+xcb) Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded Nor with Cairo + QT5: Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: qt5 (cairo+xcb) Locale: de-DE (en_AU.UTF-8); UI: en-US Calc: threaded Using: SAL_VCL_QT5_USE_CAIRO=true SAL_USE_VCLPLUGIN=qt5 libreoffice7.4 --writer
This sounds very much like tdf#150779 (s.a. duplicate tdf#151450, which also mentions registrymodifications.xcu values), which has been fixed in 7.4.2. Does this really still happen with 7.4.2, even with a fresh LibreOffice profile?
Yes. I have removed the profile and it happens on fresh profile.
Can't reproduce on Debian testing with Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Linux 6.0; UI render: default; VCL: qt5 (qfont+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded or Version: 7.4.3.2 / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Linux 6.0; UI render: default; VCL: qt5 (cairo+xcb) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
I was unable to reproduce this same behavior in Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded or Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to Armondo Lopez from comment #13) > I was unable to reproduce this same behavior in > > Version: 24.2.1.2 (X86_64) / LibreOffice Community > Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac > CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win > Locale: en-US (en_US); UI: en-US > Calc: threaded > > or > > Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb > CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win > Locale: en-US (en_US); UI: en-US > Calc: threaded Thanks for testing. Maxim (as original reporter): Do you still see the problem with LibreOffice 24.2 or newer?
I don't have access to the latest LibreOffice, as I depend on what's packaged in the FreeBSD package repository, but at some point it just started working again with Qt5. I am currently on 7.6.4.1_2 and I can confirm it works fine with Qt5.
I just wanted to add that I'm having the same issue using gtk3, so it's not qt5 related. My version info: --- Version: 7.4.7.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 2; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Debian package version: 4:7.4.7-1+deb12u5 Calc: threaded
(In reply to levstik from comment #16) > I just wanted to add that I'm having the same issue using gtk3, so it's not > qt5 related. > > My version info: > --- > Version: 7.4.7.2 / LibreOffice Community > Build ID: 40(Build:2) > CPU threads: 2; OS: Linux 6.6; UI render: default; VCL: gtk3 > Locale: en-US (en_US.UTF-8); UI: en-US > Debian package version: 4:7.4.7-1+deb12u5 > Calc: threaded Ok, but do you reproduce it with 24.8?
Not yet. 24.8 works fine for me (using appimage)