When I open a document using the StartCenter, the document window retains the size and position of the StartCenter. If I close the StartCenter and open the same document using the menu, the document window gets the size and position I want (the same as when I closed the file). When opening a document, I expect the size and position of the document window to be the same regardless of which UI I used to open it. When I open a document using the StartCenter, I want the size and position to be set the way it is when I open the file using the menu.
Seems to be [Reproducible] with "LibreOffice 3.4.3 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:302)]", but IMHO that's only a part of a bigger problem. And may be that details of the behavior are OS related- AFAIK a document should be opened with the window size it had when it was closed. My observatioons: I had 2 Writr documents named - Landscape.odt (in a low wide window) - Poortrait.odt (in a high narrow window) After closing LibO and opening one of those documents from WIN Explorer: Expected: document opens with window size it had when closing Actual: document opens with window size the last closed document had when closing. That means when I closed "Portrait.odt" as the last one terminating LibO and then restart LibO opening "Landscape.odt" from Explorer, "Landscape.odt" opens with Portrait.odt window size. All further documents I open from explorer will be opened with Portrait.odt window size. Seems to be so for documents opened from LibO "recent documents" Also during a LibO session documents will be reopened (Recent documents) with window size of latest saved / closed document, not with latest original document size. LibO expects the start center to be a normal document, when you terminate LibO closing the Start Center as last LibO element, documents will be reopened with Start Center window size, if you closed a reall document as last LibO element documents will be reopened with window size of that last document. The positioning of the reopen window seems to have different rules, currently I do not know the rules All the same with OOo 3.1.1, seems to be OOo heritage. @Shad Sterling: Can you confirm my investigation details?
I haven't tested different cases, but when I have 3 windows open with different sizes/shapes and positions, close LibO, and reopen via Finder on the same 2 files, The files all seem to have the same size/shape as the last one to close (which, in this case, prompted to save after the others were closed) with a different one of them in the same position as the last closed (in this case the lower right) and the other two on top of eachother in a different position (at the upper left, which puts the upper-left corner of each in the same place as when closed).
Since all new unconfirmed bugs start in state UNCONFIRMED now and old unconfirmed bugs were moved to NEEDINFO with a explanatory comment, all bugs promoted above those bug states to NEW and later are automatically confirmed making the CONFIRMED whiteboard status redundant. Thus it will be removed.
Please read this message in its entirety before responding. Your bug was confirmed at least 1 year ago and has not had any activity on it for over a year. Your bug is still set to NEW which means that it is open and confirmed. It would be nice to have the bug confirmed on a newer version than the version reported in the original report to know that the bug is still present -- sometimes a bug is inadvertently fixed over time and just never closed. If you have time please do the following: 1) Test to see if the bug is still present on a currently supported version of LibreOffice (preferably 4.2 or newer). 2) If it is present please leave a comment telling us what version of LibreOffice and your operating system. 3) If it is NOT present please set the bug to RESOLVED-WORKSFORME and leave a short comment telling us your version and Operating System Please DO NOT 1) Update the version field 2) Reply via email (please reply directly on the bug tracker) 3) Set the bug to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + LibreOffice is powered by a team of volunteers, every bug is confirmed (triaged) by human beings who mostly give their time for free. We invite you to join our triaging by checking out this link: https://wiki.documentfoundation.org/QA/BugTriage There are also other ways to get involved including with marketing, UX, documentation, and of course developing - http://www.libreoffice.org/get-help/mailing-lists/. Lastly, good bug reports help tremendously in making the process go smoother, please always provide reproducible steps (even if it seems easy) and attach any and all relevant material
LibreOffice 4.2.5.2 on Mac OS X 10.9.4 --- Summary: The behavior has changed in 4.2.5, but it is still inconsistent (just differently inconsistent), and still does not work as desired. Instead of depending on how the file is opened, the document window size & position now depends on weather or not the StartCenter is open when the file is opened. The desired behavior is (still) for the document window to open with the same size & position as when the same document file was most recently closed. --- Detail: I upgraded from 4.2.4 to 4.2.5 to test this with the current version. After closing all documents, then closing LibreOffice, LibreOffice launches with the StartCenter as the only window. Opening the most recently closed document from the StartCenter appears to open the document in the same window; the StartCenter disappears and the document window has the same size and position that the StartCenter had. Leaving the StartCenter open and opening the file from either the Recent Files menu or the Open Document dialog does the same thing, as does switching to and opening the file from Finder. Closing the StartCenter and then opening the file in any of the same three ways appears to open the document to the same size and position that it had when closed. Opening the file from Finder was significantly slower, even though LibreOffice was already open - it appeared to wait until I clicked on a menu (to make sure it was still responding at all) before loading the file; this was not the case when the StartCenter was left open. If I close LibreOffice with one document still open, LibreOffice still launches with the StartCenter as the only window, and reopening the same file has the same behavior as when I closed the document before closing LibreOffice (right down to waiting for me to click a window when opening the file from Finder). If I open the same file from Finder when LibreOffice is not already open, LibreOffice launches with that document as the only window (no StartCenter), and the document window has the same size and position that it had when closed. This is the same as opening from Finder when LibreOffice is open and the StartCenter is closed, except that it does not wait for a click before opening the file. I did not test multiple document behavior, such as @Rainer Bielefeld Retired's Landscape and Poortrait scenario. I separated tests for having closed the document first from having closed LibO with the document open because when I first launched 4.2.5 I opened the document from the StartCenter and then saw that there were two windows open for the same file, which I thought might have been related to the file being open when I last closed 4.2.4 (now that does not seem to be the case).
Naturally, right after I wrote that, I switched back to LibreOffice and opened another file that had been open earlier today. It also did not open to the same window size and position as when it was last closed, but to the same size as the one existing window positioned in front of the existing window and offset down and to the right each by the height of the window title.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-07-18
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
*** Bug 104325 has been marked as a duplicate of this bug. ***
Also present on MacOS, in latest 5233 and master 540 alpha
I'm not sure Bug 104325 is a duplicate; it's about creating a new document, this bug is about reopening an existing document. They're related, but I'm sure they're the same.
Typo in last comment, I meant to say I'm NOT sure they're the same. In case that wasn't clear.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Repro Version: 6.1.0.0.alpha0+ Build ID: cc1db6f2b0ebe05ae807628778835b62df00eca2 CPU threads: 4; OS: Windows 6.3; UI render: default; TinderBox: Win-x86@42, Branch:master, Time: 2017-12-02_23:45:34 Locale: nl-NL (nl_NL); Calc: CL
Dear Shad Sterling, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still present in 6.2.5. Version: 6.2.5.2 Build ID: 1ec314fa52f458adc18c4f025c545a4e8b22c159 CPU threads: 12; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded
Seems like bug 128512 is a DUP of this report.
Kubuntu 18.04, LO 6.3.2.2. I now have reproduced the thorough investigation first started by Shad. The results confirm his observations: The size and placement of the window of an LO component in which a file is displayed upon opening it depends on the opening method: 1) If you first open the LO Start Center and click on one of the file icons shown, the file is displayed in the Start Center window, ignoring the coordinates that the window of this file had last time. And the coordinates of the Start Center window are always preserved. 2) There are (at least) two ways of foregoing the Start Center: a) Either use the File > Open (recent document) menu b) or double click, in your file manager (Dolphin my case) on the particular file. Opening a file in either of these latter ways displays it with the window coordinates it had when last saved. There is, however, one exception: If, while using method #2b, the Start Center is open, then the result is as for #1. All of this is inconsistent and confusing. I concur with the other bug reporters on the request that each LO component should remember, for each of the files recently opened in it, the coordinates of each window that the file was displayed in; and this regardless of the way that the user opened the file. As long as this is not fixed, the advice for the user is to not use the LO Start Center.
*** Bug 127952 has been marked as a duplicate of this bug. ***
*** Bug 128512 has been marked as a duplicate of this bug. ***
*** Bug 75644 has been marked as a duplicate of this bug. ***
*** Bug 87465 has been marked as a duplicate of this bug. ***
*** Bug 87542 has been marked as a duplicate of this bug. ***
*** Bug 100500 has been marked as a duplicate of this bug. ***
*** Bug 112232 has been marked as a duplicate of this bug. ***
It's rather an enhancement than a bug. To summarize: * new documents may keep taking the size of the start center * opening existing documents should remember their size and position individually * the default size for the start center (and newly created documents) should follow the system standard (bug 125543, bug 55344) * an option to restore the whole workspace with multiple open documents should be considered (bug 141400, bug 146769)
*** Bug 144211 has been marked as a duplicate of this bug. ***
*** Bug 102213 has been marked as a duplicate of this bug. ***
*** Bug 101950 has been marked as a duplicate of this bug. ***
*** Bug 92737 has been marked as a duplicate of this bug. ***
*** Bug 86055 has been marked as a duplicate of this bug. ***
*** Bug 135971 has been marked as a duplicate of this bug. ***
*** Bug 121968 has been marked as a duplicate of this bug. ***
*** Bug 112332 has been marked as a duplicate of this bug. ***
We store currently the last window size independently from module and document. Meaning when a small drawing with 400 x 800px (WxH) is saved, the start center will open the next time in this inappropriate size, for example. In the various duplicate enhancement requests not only the desire to store the window size and position per module is expressed but also the wish to remember per document. A potential use case is to have document A on the left side of the screen in parallel to document B on the right. Or a spreadsheet that requires an overview to many cells at a full-screen level vs. some smaller size otherwise.
*** Bug 150615 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #35) > We store currently the last window size independently from module and > document. Meaning when a small drawing with 400 x 800px (WxH) is saved, the > start center will open the next time in this inappropriate size, for example. > > In the various duplicate enhancement requests not only the desire to store > the window size and position per module is expressed but also the wish to > remember per document. > > A potential use case is to have document A on the left side of the screen in > parallel to document B on the right. Or a spreadsheet that requires an > overview to many cells at a full-screen level vs. some smaller size > otherwise. I fully agree with this regarding per-document last positions. I would like to add that, for systems using multiple monitors, the last used monitor itself should be saved as well (unless the system is treating multiple monitors as one huge screen). Another aspect that needs recording with the document is whether or not extra panels are being displayed. I prefer to use Writer with the Navigator panel showing whereas I prefer Calc without it. However, like other settings, this appears to be a global setting which then requires me to open the navigator on Writer if the last file closed was Calc or vice-versa. I don't use the Start Center and always double-click the document in File Explorer (Windows 10) or, for commonly used documents, on their icon on my desktop, so I haven't experienced the issue with that aspect. However, after recently upgrading from 7.3.5 to 7.4.0, I found that EVERY window was opening on my left-hand monitor at quite a small initial size - my monitors are both 1920 x 1200 and the initial window was probably around 1024 x 800. This was extremely annoying as I had to reposition and resize EVERY document I opened. After finding that 7.4.1 still had the same regression, I downgraded to 7.3.6 and the problem went away and windows now (usually but not always) open on the monitor they were last used on at the last used size. I won't be upgrading past 7.3.6 until I know this regression has been fixed.
@David Viner For me on Mac OS 10.13.6 the window size per Document isn’t saved in any Version ... I tried it in 7.3.5, 7.3.6 and 7.4.1. Last Document saved in 4000 x 2000 Pixel opens the next in the same size.
Windows 11, LibreOffice 7.4.1.2 Testing Writer... With the new release, I'm finding the user-set program window size is again being respected whether the program is opened directly or indirectly by way of the document.
*** Bug 151397 has been marked as a duplicate of this bug. ***
In past "discussions" of this issue (mostly in the OpenOffice Bugzilla), it was claimed that the ODF standard does not support capturing window size and position. I just discovered a "List of LibreOffice ODF Extensions" at https://wiki.documentfoundation.org/Development/ODF_Implementer_Notes/List_of_LibreOffice_ODF_Extensions. If I understand that webpage correctly, it seems there are many additions in LibreOffice that are not supported by the ODF standard. If so, why can't additions be done to address this issue.