Bug 99112 - Restore down (unmaximising) can not remember previous window size and position across sessions
Summary: Restore down (unmaximising) can not remember previous window size and positio...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
5.1.2.2 release
Hardware: All All
: low trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: User-Profile Maximized-Window
  Show dependency tree / graph
 
Reported: 2016-04-06 07:21 UTC by odinatlas
Modified: 2024-05-06 14:40 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
restore down bug (155.06 KB, image/png)
2016-04-06 07:21 UTC, odinatlas 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description odinatlas 2016-04-06 07:21:14 UTC 
Created attachment 124117 [details]
restore down bug

I launch Lebreoffice and restore down window, then close and launch again, it will remembers the windows aize and position.

but maximize window, then close and launch again,when restore down, it will not.
as attachment
Comment 1 odinatlas 2016-04-06 07:23:45 UTC 
so if libreoffice can be set default windows size like version 4.1.6, it will be fine.
Comment 2 odinatlas 2016-04-09 02:39:23 UTC 
I am sure Settings of Libreoffice window size and postion is in "LibreOffice 5\user\registrymodifications.xcu"
but I can not find it out.
Comment 3 odinatlas 2016-04-09 02:49:18 UTC 
The value of windows and position is below

<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>4,46,1672,972;4;0,0,0,0;</value></prop></item>
Comment 4 Buovjaga 2016-04-26 07:46:02 UTC 
Reproduced.
Note for testers: "Restore down" means switching from maximized to non-max.

Win 7 Pro 64-bit Version: 5.2.0.0.alpha1+
Build ID: d848960a3e77a8608a48f3ba394928c955f1e2d9
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-04-25_06:03:51
Locale: fi-FI (fi_FI)
Comment 5 odinatlas 2017-03-19 02:45:34 UTC 
maybe it is not s bug,
Adapt to it.
Comment 6 QA Administrators 2018-03-20 03:35:28 UTC Comment hidden (obsolete)
Comment 7 QA Administrators 2020-03-20 02:39:22 UTC Comment hidden (obsolete)
Comment 8 jollytall 2020-08-20 04:42:15 UTC 
After upgrading Debian 9 to Debian 10 on AMD64 I have the same bug.
LibreOffice version used (as in Debian10 repository) is:
Version: 6.1.5.2
Build ID: 1:6.1.5-3+deb10u6
CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; 
Locale: en-GB (en_US.UTF-8); Calc: group threaded

Tested in Calc and Writer. If at exit the window is in restored state/size (i.e. custom size) then the next load is OK. If the window is maximized when exit, the next load is also maximized (so-far OK). But when the freshly opened maximized window is changed to custom size, the custom size is not the last size, but something small in the upper left side of the screen.

So it seems that when it exits, if the window is maximized, it does not save or does not save correctly the custom size (what it knows well, while running, i.e. switching between custom size and maximized works well until exit).

In earlier version I did not have this. Since the original bug is from 2016, it seems that it came back with the new Office.
Comment 9 QA Administrators 2022-08-29 06:44:54 UTC Comment hidden (obsolete)
Comment 10 Buovjaga 2022-09-24 14:27:26 UTC 
Still repro:

1. Launch scalc.exe
2. Change window width to half
3. Maximise
4. Exit
5. Launch scalc.exe
6. Unmaximise

Window width is not half.

I also repro on Linux, but not the tiny size mentioned in comment 8.

Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 00c5b0ca9264c5440bc70a68c425127ba5a47003
CPU threads: 2; OS: Windows 10.0 Build 19044; UI render: default; VCL: win
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded Jumbo
Comment 11 Jeff Fortin Tam 2023-04-18 21:33:53 UTC Comment hidden (obsolete)
Comment 12 Jeff Fortin Tam 2024-05-06 14:40:13 UTC 
Correction to my previous comment #11: the problem still happens with demaximizing, after all, even with version 24.2.x on Wayland.

Demonstration video: https://youtu.be/dv8gb1GljzU
(from my observations in https://bugs.documentfoundation.org/show_bug.cgi?id=125543#c58 ...)

Buovjaga's reproduction steps in comment #4 still apply; I had misunderstood them as being about half-tiling, but they simply meant resizing the window with to roughly half, as part of the testing procedure.

The key is to close the app while maximized, before unmaximizing, which will then unmaximize "to the size of a maximized window";
otherwise, unmaximizing "before closing the app first" would not trigger the bug, it would unmaximize "to the previous/smaller window size" of the current session.

In case this might help, some implementation reference docs/tips: https://developer.gnome.org/documentation/tutorials/save-state.html (you can see there that the maximization state is saved independently from width/height, but also you need to infer that width/height shouldn't get saved while in maximized state, only in windowed state).

---

Tested on:

Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 8; OS: Linux 6.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Flatpak
Calc: threaded