Created attachment 182204 [details] Screenshot of opened LO - no recent documents available Open LO 7.4.1.1. Every time it opens with a small part of the screen. No "Recent documents" in main screens are available. Have tested with new profile: Only the fist time LO starts will normal (nearly full) screen. Second start will show only the left pane of the screen. Screenshot added. Version: 7.4.1.1 / LibreOffice Community Build ID: 0a046a10cbf1679eea5538bd3ab63156caa3a036 CPU threads: 6; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
No issue on Windows builds, StartCenter is populated with thumbnails of MRU history entries taken from profile Version: 7.4.1.1 (x64) / LibreOffice Community Build ID: 0a046a10cbf1679eea5538bd3ab63156caa3a036 CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
At first I didn't reproduce with current 7.4 as kf5. But when I did with older 7.4 I saw it also with current 7.4. Luckily not with master 7.5+. I close as WFM. Please test yourself, easy as Appimage per https://wiki.documentfoundation.org/Installing_in_parallel/Linux
In addition to testing with master, please search existing bugs and for kf5 set bug 102495 in Blocks. That focuses bug as general testers that look for unconfirmed bugs may not have KDE etc.
(In reply to Timur from comment #2) > At first I didn't reproduce with current 7.4 as kf5. But when I did with > older 7.4 I saw it also with current 7.4. > Luckily not with master 7.5+. I close as WFM. > Please test yourself, easy as Appimage per > https://wiki.documentfoundation.org/Installing_in_parallel/Linux I have installed many versions parallel. So I could test this again and again with a new profile. First start will work with LO 7.4.1.1. Closing LO and reopening will show the bug. This bug isn't solved in any way.
@Ilmari, @Michael, any chance you could bisect this issue on your side ?
I'm wondering whether this issue was introduced by https://cgit.freedesktop.org/libreoffice/core/commit/?h=libreoffice-7-4&id=105d129683b0e88bbb8e682d308786a587aa895f
Regression introduced by: author Jan-Marek Glogowski <glogow@fbihome.de> 2022-06-02 22:42:20 +0200 committer Jan-Marek Glogowski <glogow@fbihome.de> 2022-06-08 18:17:17 +0200 commit ea5a0918c8c32309821ab239c4b95f4d6a3b5c12 (patch) tree 04ff84b7c076a2f178e90d0eb32eb1731b10fd3c parent d4123356c61db269651e950a0a2cc93e6d801c90 (diff) VCL add vcl::WindowPosSize abstract class Bisected with: bibisect-linux64-7.4 Adding Cc: to Jan-Marek Glogowski
In master, the issue got fixed by author Luboš Luňák <l.lunak@collabora.com> 2022-06-09 18:23:44 +0200 committer Luboš Luňák <l.lunak@collabora.com> 2022-06-13 10:36:15 +0200 commit b7b06f28d5728c2c33c073df35ac0c3bcc51e583 (patch) tree 0d1d84194ade8b3cd8598c80ab6e763649906b84 parent 930ba0c1ec9620641f58573d4bcdb9755be94d11 (diff) avoid uninitialized data when handling WindowState But this patch got reverted in libreoffice-7-4 because of bug 150236
I have difficulties reproducing this, but I sometimes see Writer or Base starting minimized when the window was maximized on closing in the previous run with the libreoffice-7-4 branch as of commit 23d607b104013e412295ac83956edc74e94ed2df. Given that ea5a0918c8c32309821ab239c4b95f4d6a3b5c12 mentions it "Should mostly be a refactoring" and nothing on 7-4 depends on it (except for a single place that was using the new name of a flag), reverting the commit on 7-4 only seems to be the easiest way forward to me. Suggested Gerrit change: https://gerrit.libreoffice.org/c/core/+/139903
Hi Michael, as mentioned in IRC: <buovjaga> x1sc0: I am investigating tdf#150856 Have to be careful as the profile has to be cleared with each bisect and the test performed twice
Tested this again: Bug appears only if LO has been maximized before closing. Doesn't recognize this, because I'm only working with LO maximized.
(In reply to Xisco Faulí from comment #10) > Hi Michael, > as mentioned in IRC: > <buovjaga> x1sc0: I am investigating tdf#150856 Have to be careful as the > profile has to be cleared with each bisect and the test performed twice @Xisco: Thanks, also for the detailed analysis above! I had read Ilmari's bug 150856 comment 11 but used the seemingly simpler scenario described in the bug description in tdf#150856 ("Same behavior when starting Tools → Macros → Edit Macros in Base.") but that still wasn't reliably reproducible with a cleared user profile and testing twice. However, testing the original scenario in tdf#150856 with a cleared user profile and opening the dialog makes the issue reproducible reliably here for me (since the window is opened maximized in the first run). (In reply to Robert Großkopf from comment #11) > Tested this again: Bug appears only if LO has been maximized before closing. > Doesn't recognize this, because I'm only working with LO maximized. Good point. Indeed, when I do the following, I can reproduce reliably: 1) clear user profile 2) open a Base document 3) close LO 4) open Start Center 5) maximize window 6) close window 7) open Start Center again The issue is no more reproducible for me with https://gerrit.libreoffice.org/c/core/+/139903 in place.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/1c0f44cbacb4bcefcf383586e7ccd32d47388fa4 tdf#150779 tdf#150856 Revert "VCL add vcl::WindowPosSize ... It will be available in 7.4.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Verified in Version: 7.4.2.0.0+ / LibreOffice Community Build ID: 1c0f44cbacb4bcefcf383586e7ccd32d47388fa4 CPU threads: 8; OS: Linux 5.10; UI render: default; VCL: kf5 (cairo+xcb) Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded @Michael, thanks for the revert
*** Bug 150988 has been marked as a duplicate of this bug. ***
*** Bug 151067 has been marked as a duplicate of this bug. ***
*** Bug 151078 has been marked as a duplicate of this bug. ***
*** Bug 151450 has been marked as a duplicate of this bug. ***
*** Bug 151493 has been marked as a duplicate of this bug. ***
*** Bug 151414 has been marked as a duplicate of this bug. ***
Seems to also solve bug 125543 (after starting in safe mode the window becomes about 50% of the screen size now on un-maximizing - which is quite ugly on wide screens but not an issue anymore).