Description: After upgrading (updating) LO when I open LO it opens to covering only about 3/4 of the screen. Steps to Reproduce: 1.Install latest version 2.Double click LO desktop icon to open 3. Actual Results: Opens to 3/4 screen Expected Results: Should open maximized or full screen. Reproducible: Always User Profile Reset: No Additional Info: The only way to get it to open full screen is by doing right click on the Desktop icon click on Properties - click on Shortcut tab then down to Run: and pick Maximized the Apply then OK. Has happened on the last two versions. LO 7.4.0.1 & 7.4.0.2 Have not done a total uninstall and reinstall.
Can not confirm Version: 7.4.0.2 (x64) / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded With fresh profile the StartCenter (SC) will open to 3/4 size of a FullHD display. The StartCenter will not open to full display unless intentionally set that way, and never from a default profile. Initial launch of a module from the SC will receive the same dimension as the SC. While directly launching will take full display on module's initial launch, or pick up last used size for the module on subsequent launches. Please retest. But first, delete/rename user profile (%APPDATA%/LibreOffice) to reset initial conditions, and then launch modules directly, and via the SC.
I tried resetting the Profile. That did not fix the problem. I did a complete uninstall which included cleaning the Registry and then reinstalled LO. The problem is still there. So to make it work I reapplied the Run: Maximize. For now that solves my problem.
sigh... => NAB
Found this. https://ask.libreoffice.org/t/libreoffice-7-4-does-not-open-in-a-maximized-window/80124 Seems like I am not the only one with this problem. It is a bug.
Confirmed on a 7.4.0.2 build. Seems like the frame values for ooSetupFactoryWindowAttributes are not actually being written into user profile (registrymodifications.xcu). The XML stanzas are there, but the value is blank. No change to source setup.xcu, so not clear why profile is not being populated. With recent build of master against 7.5.0 they are present. And they were present in 7.3.4.2 with a cleared user profile. =-ref-= Version: 7.4.0.2 (x64) / LibreOffice Community Build ID: 1512ce97d7ed39dce3121f7e15651fd8895f950e CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
I uninstalled LO 7.4.0.2 and reinstalled LO 7.3.5.2 and so far it opens normally (Maximized/Full screen) without having to make the Run: change.
This bug still exist on LO 7.4.0.3.
Confirmed /a administrative install of Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded No values for ooSetupFactoryWindowAttributes are being written into user proile. The stanzas are there for modules that are launched, but they remain empty. While no issue with recent builds of master against 7.5, something is off with the 7.4 build and needs a tweak.
@Xisco, Cloph -- a blocker?
(In reply to V Stuart Foote from comment #9) It can't ever be a blocker, or even a major. It does not make work with the program impossible, or make it difficult - it is minor, even if regression. (In reply to jlerner10 from comment #0) > Steps to Reproduce: > 2.Double click LO desktop icon to open > > Actual Results: > Opens to 3/4 screen > > Expected Results: > Should open maximized or full screen. Why? Either I do not understand something, or there is no good steps yet here.
LO 7.4.x does not remember the last used window position and size, which may annoy a lot of users.
(In reply to Mike Kaganski from comment #10) > (In reply to V Stuart Foote from comment #9) > > It can't ever be a blocker, or even a major. It does not make work with the > program impossible, or make it difficult - it is minor, even if regression. > Sure, and it is even resolved for 7.5.0; but why allow it out when it could be avoided, probably with minimal effort. Kind of the point of doing multiple betas for pending major releases. Seems something trivial has slipped. Take care of it now to limit any bad feelings for early testers/adopters. > (In reply to jlerner10 from comment #0) > > Steps to Reproduce: > > 2.Double click LO desktop icon to open > > > > Actual Results: > > Opens to 3/4 screen > > > > Expected Results: > > Should open maximized or full screen. > > Why? Either I do not understand something, or there is no good steps yet > here. On Windows at least, we get no recording to profile of each modules placement and frame size. So the modules will open in unexpected locations and sizes--especially as compared to workflows with prior releases.
(In reply to V Stuart Foote from comment #12) So is there a "open LibreOffice, expand it to full screen, and close" step before step 2 missing? Initially I assumed you all were talking about a shortcut properties - e.g., on Windows, you may assign such settings to shortcuts; and I assumed that it was "set up shortcut to open fullscreen" step that was missing.
(In reply to Mike Kaganski from comment #13) > (In reply to V Stuart Foote from comment #12) > So is there a "open LibreOffice, expand it to full screen, and close" step > before step 2 missing? Initially I assumed you all were talking about a > shortcut properties - e.g., on Windows, you may assign such settings to > shortcuts; and I assumed that it was "set up shortcut to open fullscreen" > step that was missing. No. With a clean profile. swriter.exe, scalc.exe, sdraw.exe open to full screen. But with soffice.exe (StartCenter) open, first module opens to the StartCenter frame size. Next module launched *also* gets the frame size for the StartCenter. For release builds before 7.4.0.1 and in 7.5.0alpha0+, next module gets its size from ooSetupFactoryWindowAttributes values (IIUC) recorded to user profile. But expect that is just a manifestation of the actual issue. I can not judge for sure because I can't follow how it is plumbed to write back to profile, but there was Jan-Marek's refactoring vcl::WindowPosSize [1] in ea5a0918c8c32309821ab239c4b95f4d6a3b5c12 that is in at 7.4.0.1 =-ref-= https://gerrit.libreoffice.org/c/core/+/135426
Sigh. I do not see what specific steps I need to do in LibreOffice before and after 7.4.0.1 to compare. I try with 7.3.0.3, and I see the same as with 7.4.0.2. I would expect at least experienced contributors like V Stuart Foote to understand the importance of exact steps. * I clean user profile using Help->Restart in Safe Mode (I check both options under Reset to factory settings, and Apply changes and restart). * I see the start center opening in windowed mode. * I close it without any resize or move. * I run swriter.exe * I see it opened in full screen * I close it without a resize or move * I run soffice.exe and it is again in windowed mode, as expected * Without closing or resize or move, I run swriter.exe and see it replacing start center in its windowed mode (as expected) * I start swriter.exe again, and see a new Writer window in windowed mode **both with 7.3.0.3 and 7.4.0.2 (with profiles cleared separately for each).**
(In reply to Mike Kaganski from comment #15) > * I start swriter.exe again, and see a new Writer window in windowed mode Likely I messed up with this step the first time - with 7.3.0.3, after a re-check, I see that the second Writer opened full screen (but 7.4.0.2 continues behaving as I wrote above). Maybe that was the difference that is discussed here?
@Mike, I'm sorry I didn't think specific steps were relevant here. The OP's "Not open full screen" is just the most obvious, but issue affects any of the potential WindowState modes, or a recorded screen size & position. Instead, one can directly examine settings recorded to registrymodifications.xcu for each module's ooSetupFactoryWindowAttributes stanza. They are populated with position and mode details for builds prior to 7.4.0.1 through 7.4.0.3, and are again populated in current builds of master against 7.5.0alpha0+ So something was completed for master that did not get back ported to 7.4.0
Then what is required is two bibisects, one for the regression, another for the fix. If the latter is not possible at the moment, e.g. because 7-5 bibisect repo has not been updated yet, it's perfectly OK to have 7.4.0 released with this minor issue, and bibisect at a later time. No reason to spend much time trying to bisect or debug.
(In reply to Mike Kaganski from comment #18) > Then what is required is two bibisects, one for the regression, another for > the fix. If the latter is not possible at the moment, e.g. because 7-5 > bibisect repo has not been updated yet, it's perfectly OK to have 7.4.0 > released with this minor issue, and bibisect at a later time. No reason to > spend much time trying to bisect or debug. Yes, agree. Should note the impact on users upgrading. As each LO module is launched its window state is being corrupted with empty values recorded back to .xcu profile. Clearing the profile has each module start with empty values, but folks migrating will loose UI configuration of their desktop. It is a major release, so guess we can accept clobbering profiles for early testers/adopters--but it will be an annoyance. Avoidable?
I do hope this gets fixed before it gets to be the final release version. It will be annoying if you have to maximize the modules each time you start LO. Still on LO 7.3.5.2 Thanks to all who have responded.
I'm sorry but the steps were not clear at all, it took me more than an hour to find the way to reproduce it... Steps to reproduce: 1. Clean the profile 2. Launch soffice 3. Open writer from the start center 4. Maximize the window 5. Close LibreOffice 6. Launch Writer -> it should be maximized
(In reply to Xisco Faulí from comment #21) > I'm sorry but the steps were not clear at all, it took me more than an hour > to find the way to reproduce it... > > Steps to reproduce: > 1. Clean the profile > 2. Launch soffice > 3. Open writer from the start center > 4. Maximize the window > 5. Close LibreOffice > 6. Launch Writer > > -> it should be maximized Yep, like that. Or you could just look in the user profile for any launch ;-)
In master, this issue got fixed by https://cgit.freedesktop.org/libreoffice/core/commit/?id=8b6000f6075725b2e17b8fa745251ea96d7185f1
(In reply to Xisco Faulí from comment #23) > In master, this issue got fixed by > > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=8b6000f6075725b2e17b8fa745251ea96d7185f1 No, that [1] is already in the 7.4.0.1 pre-release (built 2022-07-06), right? =-ref-= [1] https://gerrit.libreoffice.org/c/core/+/135809
(In reply to V Stuart Foote from comment #24) > (In reply to Xisco Faulí from comment #23) > > In master, this issue got fixed by > > > > https://cgit.freedesktop.org/libreoffice/core/commit/ > > ?id=8b6000f6075725b2e17b8fa745251ea96d7185f1 > > No, that [1] is already in the 7.4.0.1 pre-release (built 2022-07-06), > right? > > =-ref-= > [1] https://gerrit.libreoffice.org/c/core/+/135809 no, it's not
Created attachment 181816 [details] cgit of 8b6000f in 7.4.0 (In reply to Xisco Faulí from comment #25) ... > > [1] https://gerrit.libreoffice.org/c/core/+/135809 > > no, it's not Umm, you sure? If so it fooled me.
Regression introduced by: author Luboš Luňák <l.lunak@collabora.com> 2022-06-09 18:23:44 +0200 committer Caolán McNamara <caolanm@redhat.com> 2022-06-20 10:07:32 +0200 commit 8b46093b27b065ac9b537348ed909530b5ffd588 (patch) tree 1073ee425b698f56a5bab4d88f4206e69485e1e0 parent fee9ef889ac85c6758aef9fb2b8101424cf3c870 (diff) avoid uninitialized data when handling WindowState Bisected with: win64-7.4 Adding Cc: to Luboš Luňák
*** Bug 149957 has been marked as a duplicate of this bug. ***
*** Bug 150478 has been marked as a duplicate of this bug. ***
*** Bug 150482 has been marked as a duplicate of this bug. ***
*** Bug 150485 has been marked as a duplicate of this bug. ***
*** Bug 150003 has been marked as a duplicate of this bug. ***
*** Bug 150212 has been marked as a duplicate of this bug. ***
*** Bug 150493 has been marked as a duplicate of this bug. ***
Windows users simple temp workaround: 1. On the desktop icon: Right click -> Properties 2. Change "Run:" to "Maximized"
My take on it, to revert the problematic commit only in libreoffice-7-4 branch: https://gerrit.libreoffice.org/c/core/+/138534
(In reply to Xisco Faulí from comment #36) > My take on it, to revert the problematic commit only in libreoffice-7-4 > branch: https://gerrit.libreoffice.org/c/core/+/138534 That is only a satisfactory workaround if you are in the habit of running LibreOffice maximised.
(In reply to gfowler1 from comment #35) > Windows users simple temp workaround: > > 1. On the desktop icon: Right click -> Properties > > 2. Change "Run:" to "Maximized" This is only a satisfactory workaround if you are in the habit of running LO maximised. No window size or position is remembered, maximised or other. (Sorry, replied to wrong comment just now.)
*** Bug 150536 has been marked as a duplicate of this bug. ***
"KamilLanda: Yes, the bug is in 7.4.0.1 and 7.4.0.2, but I tested it in 7.5.0.0.alpha0+ and it is OK"
*** Bug 150513 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/105d129683b0e88bbb8e682d308786a587aa895f tdf#150236: Revert "avoid uninitialized data when handling WindowState" It will be available in 7.4.1. 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.
I found a solution, at least for me: Uninstall 7.4.0.3 and reinstall 7.3.5. Because I have two monitors. Maximizing the program window is not a suitable workaround.
Since this issue is only reproducible in libreoffice-7-4 branch and the problematic commit has been reverted in that branch, we can call this issue fixed. Please test it with a daily build from https://dev-builds.libreoffice.org/daily/libreoffice-7-4/Win-x86_64@tb77-TDF/current/?C=N&O=D ( wait one or two days until a new build is created containing the revert patch )
*** Bug 150580 has been marked as a duplicate of this bug. ***
*** Bug 150584 has been marked as a duplicate of this bug. ***
Tested nightly build dated 8-23-2022 Issue appears to have been fixed.
With commit of comment 42, in a nightly build against 7.4.1, component windows are again opening as set and the ooSetupFactoryWindowAttributes are receiving values. =-testing-= Version: 7.4.1.0.0+ (x64) / LibreOffice Community Build ID: 34edaf8249107c4216fdaffe450d287a1908a0de CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Version 7.4.1.0.0, obtained from nightly builds, also fixes the dual-monitor issue of Writer loading on the wrong monitor at the wrong size (originally reported as Bug No. 150485)
Using version 7.4.1.0.0, obtained from nightly builds... If I open Writer or Calc and set the window position and size, close the program, and reopen them, the window position and size are retained. So the issue is fixed. However, for example, if I then select a .odt file, right-click and select Open with / LibreOffice, when the document is opened, the position and window size that I set previously is not respected. So the issue persists in a different context.
(In reply to Jim Byram from comment #50) > Using version 7.4.1.0.0, obtained from nightly builds... > > If I open Writer or Calc and set the window position and size, close the > program, and reopen them, the window position and size are retained. So the > issue is fixed. > > However, for example, if I then select a .odt file, right-click and select > Open with / LibreOffice, when the document is opened, the position and > window size that I set previously is not respected. > > So the issue persists in a different context. Hi Jim, all, Thansk for testing this issue. Could you please create a follow-up report for the second issue?
Closing this one
*** Bug 150636 has been marked as a duplicate of this bug. ***
*** Bug 150661 has been marked as a duplicate of this bug. ***
*** Bug 150669 has been marked as a duplicate of this bug. ***
*** Bug 150672 has been marked as a duplicate of this bug. ***
*** Bug 150713 has been marked as a duplicate of this bug. ***
*** Bug 150722 has been marked as a duplicate of this bug. ***
*** Bug 150747 has been marked as a duplicate of this bug. ***
*** Bug 150772 has been marked as a duplicate of this bug. ***
*** Bug 150919 has been marked as a duplicate of this bug. ***
Not sure if it's the same issue, by LO is not visible for me upon launching (but looks like it opened off-screen, to the upper-left corner and beyond), till I set "Maximize" via the right click. Version: 7.4.1.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: he-IL (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.4.1~rc2-0ubuntu0.22.04.1~lo1 Calc: threaded Operating System: Kubuntu 22.04 KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-47-generic (64-bit) Graphics Platform: X11 Processors: 4 × AMD A8-6500T APU with Radeon(tm) HD Graphics Memory: 7.0 GiB of RAM Graphics Processor: AMD ARUBA
Boaz, it's more likely KDE specific, like bug 150779 that's also 7.4 and not master 7.5+.
*** Bug 150944 has been marked as a duplicate of this bug. ***
*** Bug 151026 has been marked as a duplicate of this bug. ***
In version 7.4.1.x the phenomenon is solved.
*** Bug 151067 has been marked as a duplicate of this bug. ***
It may be worthwhile to see if there are any updates or patches available for the program if LibreOffice 7.4 isn't opening in full-screen mode https://eggy-car.com