Created attachment 182204 [details]
Screenshot of opened LO - no recent documents available
Open LO 126.96.36.199.
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.
Version: 188.8.131.52 / 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
No issue on Windows builds, StartCenter is populated with thumbnails of MRU history entries taken from profile
Version: 184.108.40.206 (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
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
I have installed many versions parallel. So I could test this again and again with a new profile.
First start will work with LO 220.127.116.11.
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 <email@example.com> 2022-06-02 22:42:20 +0200
committer Jan-Marek Glogowski <firstname.lastname@example.org> 2022-06-08 18:17:17 +0200
commit ea5a0918c8c32309821ab239c4b95f4d6a3b5c12 (patch)
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 <email@example.com> 2022-06-09 18:23:44 +0200
committer Luboš Luňák <firstname.lastname@example.org> 2022-06-13 10:36:15 +0200
commit b7b06f28d5728c2c33c073df35ac0c3bcc51e583 (patch)
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:
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":
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:
Affected users are encouraged to test the fix and report feedback.
Version: 18.104.22.168.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
@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).