Writer has always had a feature of (optionally) restore last edited position on ODT reopen. Since OOo version 2.0, it restores it for the author of last edits [1]. The logic/data for restoring the position is unchanged since the beginning [2], and is implemented in SwView::ReadUserDataSequence (sw/source/uibase/uiview/view.cxx) by reading ViewLeft and ViewTop from ODT's settings.xml, and calling SwCursorShell::SetCursor to navigate to that point. The mentioned values are defined as coordinates related to application window, as shown in the steps below. This makes the restoration of the position error-prone, dependent on application window size, multi-page view, ongoing e-layout, etc. Steps: 0. Make sure to enter some information into Options->LibreOffice->User Data (First/last name); 1. Open attachment 169498 [details] from bug 140147, make sure to set zoom to 150, single-page view (controls at the right of the status bar), maximize Writer, go to end of the document (Ctrl+End), add a space and save. 2. File->Reload => this makes the cursor be placed at the correct paragraph (the one starting with 16 "6"), but at the start of it instead of at the end where the actual last edit was. 3. Restore Writer window (un-maximize) so that the page does not fit horizontally into the window (horizontal scrollbar appears at the bottom), File->Reload => this makes the cursor to be at some non-starting position of the same last paragraph (depends on size of the Writer window, ultimately it appears at the last position of the last paragraph). 4. Select "Multiple-page view" and zoom out to fit two pages in the Writer window, File->Reload => this fails to restore the position completely, making cursor appear in front of the first document's paragraph. Using "Go to last position" function (Shift+F5) restores the position on the steps #2 and #3, but not on the step #4. There are multiple problems reported about unreliable work of the feature (see e.g. bug 140147; multiple questions on Ask mention breakages around v.4.2, and also misbehavior in different other versions) even for people who made sure to have user information properly set. Also the spec [2] mentions that even prior to OOo 2.0, there were similar problems (see opinion of ES in section 8.0.1 line 153): > I already see bugs related to "sometimes document does not open the same..." On the other hand, see how the last position is implemented in DOCX. tdf#112740 describes the markup that inserts a special bookmark right into the related paragraph (word/document.xml): > <w:p> > <w:bookmarkStart w:id="0" w:name="_GoBack" /> > <w:bookmarkEnd w:id="0" /> > </w:p> which obviously makes the position unambiguous, not dependent on any unrelated environment details or concurrency problems. We could possibly use some existing mechanism (bookmark with a special name?), or introduce an extension, to also store the position in the document flow in content.xml (additionally to backward-compatible view information in settings.xml), and use that when exists. Note that we currently import the Word's "_GoBack", which is shown in the Navigator; I suppose that having an own bookmark of that kind (or even of the same name) would not hurt. [1] https://bz.apache.org/ooo/show_bug.cgi?id=43146 [2] http://specs.openoffice.org/appwide/open_doc_behavior/OpenDocumentBehavior.sxw
Created attachment 171059 [details] Screen cast of described unreliable last position restore function
@Mike, * Not opposed, but if we abandon the current view shell based ViewTop ViewLeft calculations [1] on bIsOwnDocument, think we'd still like some way to use the <Shift>+<F5> for a stack of recent cursor positions, i.e. bug 92821 Jim R. had tweaked the Navigation stack for the "Recency" mode of the Navigator, but 115817, are those view shell cursor positions also, or something else that could be picked up and written out to ODF? =-ref-= [1] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/uiview/view.cxx?r=c0936ba2#1297
This problem of Libre Office Writer opening at the top of the document rather than the last cursor position when last save seems to reoccur regularly. I am using version 7.1.6.2 and it's doing it again. Before installing this version the older version 7.1.5.2 was reopening at last cursor position as expected. Now it seems all my Writer documents open at the top but my spreadsheets open at the last position. I have tried the supposed corrections (1) entering a first name in the box pulled up by ALT+F12 and in the User Data tab and (2) opening File>Properties>General and making sure the two boxes Apply user data and Save preview were both checked. Same infernal problem. Some are instructing to use the later version 7.2 which is supposedly for those wanting latest features but not fully verified. That does not sound like a real solution. Can someone fix this continual error?
*** Bug 150114 has been marked as a duplicate of this bug. ***
*** Bug 150787 has been marked as a duplicate of this bug. ***
*** Bug 152097 has been marked as a duplicate of this bug. ***
*** Bug 140147 has been marked as a duplicate of this bug. ***
The status is still UNCONFIRMED. Shouldn't it be changed to NEW? For those interested, here is a set of macros that mimic MS Word behavior (and one of the proposed solutions): https://forum.openoffice.org//en/forum/viewtopic.php?t=108684 Assign the 2 macros (1 to set the bookmark, 1 to retrieve the position) to buttons or events for example. Can take a few seconds or need to run the macro several times to retrieve the position, depending on the length and complexity of the document (the repagination has to be finished first). Note: several versions available in the forum discussion.
*** Bug 92821 has been marked as a duplicate of this bug. ***
Marking as NEW given the number of duplicates.
*** Bug 151427 has been marked as a duplicate of this bug. ***
*** Bug 152328 has been marked as a duplicate of this bug. ***
It would be great, if someone could solve this bug. This is an important feature, especially, if you work with many text documents every day. The last version of LibreOffice that works for me (under Linux and Windows) is 7.2.7.2. In every later version this bug is present.
*** Bug 104626 has been marked as a duplicate of this bug. ***
In 7.5 beta1: Version: 7.5.0.0.beta1 (X86_64) / LibreOffice Community Build ID: 3aca23eec42e9d6fbe57071d7633ae1fc4bc5fcc CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Still unreliable, slightly different results for me: From description: - Step 2: cursor in last line of page 3 - Step 3: cursor at two thirds of page 2 - Step 4: cursor at the beginning of page 3 Back in 7.2: Version: 7.2.7.2 / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded From description: - Step 2: correct position - Step 3: correct position - Step 4: cursor at beginning of document All over the place, but as in comment 13, 7.2.7 seemed to behave less erratically. Related Bug 146988 (considered to be a regression) saw an attempt at fixing it in commit a3d4f7e8fb714aa987c542c8d6c8822a41818701, for version 7.4.0 Upping the priority because there's 7 duplicates, many related bugs, and it affects accessibility.
(In reply to Stéphane Guillou (stragu) from comment #15) > In 7.5 beta1: > > Version: 7.5.0.0.beta1 (X86_64) / LibreOffice Community > Build ID: 3aca23eec42e9d6fbe57071d7633ae1fc4bc5fcc > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded > > Still unreliable, slightly different results for me: > > From description: > - Step 2: cursor in last line of page 3 > - Step 3: cursor at two thirds of page 2 > - Step 4: cursor at the beginning of page 3 > > Back in 7.2: > > Version: 7.2.7.2 / LibreOffice Community > Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded > > From description: > - Step 2: correct position > - Step 3: correct position > - Step 4: cursor at beginning of document > > All over the place, but as in comment 13, 7.2.7 seemed to behave less > erratically. > > Related Bug 146988 (considered to be a regression) saw an attempt at fixing > it in commit a3d4f7e8fb714aa987c542c8d6c8822a41818701, for version 7.4.0 > > Upping the priority because there's 7 duplicates, many related bugs, and it > affects accessibility. Thank you for upping the priority!
I can confirm that this problem persists in version 7.4.3.2. When saving my personal document with the cursor on page 13/30, Re-opening it sends the cursor to page 22/30. Attempting to reproduce the steps in the OP, with the sample document gives the following results: Step 2: Reload shows the last page but sends cursor to middle of page 2. Entering any text will have the view jump to that page. Step 3: Reload gives the exact same results as step 2. Step 4: Reload works as expected, with the view and cursor remaining on page 4, at the end of the line. Nb: The workaround in the OP (pressing SHIFT+F5 to restore last position) works well enough, but I would not have known about it without a visit to this thread.
but if the document has tables, no one of these solution works, we hope for a solution soon. thanks
Unfortunately, the bug also persists in the last version of LibreOffice Fresh 7.4.4.2. I have to mention that I tested (under Ubuntu Linux) only the Appimage version, leaving the deb-version installed (in my case, version 7.2.7.2; as I mentioned above in comment 13, it’s the last version that works for me, i.e. where the bug isn’t present). But I guess the result would be the same: the Appimage version takes over the data and settings from the profile folder. Because I was using both versions of the program in parallel, an interesting detail emerged: If I save an edited document with version 7.2.7.2 and reopen it with version 7.4.4.2, the document opens to the right place, the last place where edits occurred. If I reopen it again with 7.4.4.2, the bug occurs again. It would be a great relief if this bug could be solved in one of the next LibreOffice releases, because it is an important function, even if it is optional.
*** Bug 153263 has been marked as a duplicate of this bug. ***
As there are several mentions of 7.2 working better - it may be useful to attach a sample document, which restores the position in 7.2, and does not in later versions - it could be useful to check if there was a specific regression that could be fixed, to at least make the problem less severe. But that would be fixing another problem; so if you feel like that, please do it in another report (e.g., one of those that are marked duplicate). Thanks.
*** Bug 153113 has been marked as a duplicate of this bug. ***
*** Bug 140368 has been marked as a duplicate of this bug. ***
*** Bug 140860 has been marked as a duplicate of this bug. ***
*** Bug 141024 has been marked as a duplicate of this bug. ***
*** Bug 142768 has been marked as a duplicate of this bug. ***
Hopefully this is cleaned up now, I marked all recent reports as duplicates of bug 140147, which was an on-off regression since 7.1.
No change in the last version of Libreoffice Fresh 7.5.2.2. Is there any chance that this bug will be solved?
(In reply to Mibu from comment #29) > No change in the last version of Libreoffice Fresh 7.5.2.2. Is there any > chance that this bug will be solved? You're probably mistaking this for bug 140147.
This problem has existed for almost a year now. Years before this did not exist. And yet it seems to be a problem to finally eliminate this bug. It would be desirable and gratifying to be able to close this book.
*** Bug 155824 has been marked as a duplicate of this bug. ***
In my Linux version 7.5.3.2 the "Restore editing view" command (default Shift-F5 but I use it with Shift-Del) takes you to last edit position, which normally corresponds with the last position of the cursor.
Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: it-IT (it_IT.UTF-8); UI: it-IT Ubuntu package version: 4:7.5.4~rc2-0ubuntu0.20.04.1~lo1 Calc: threaded Bug still present. I do also believe that if it doesn't hurt (like Mike wrote) we could implement the very same tags in the document (or settings) to obtain a more precise behavior.
It affects also the latest version of LO 7.5.5.2.
Hello, you can try this to get around this bug. 1 - Create this macro in MyMacros named OpenDoc Sub OpenDoc Dim document as object, dispatcher as object, pageCount as Integer pageCount = ThisComponent.CurrentController.PageCount document = ThisComponent.CurrentController.Frame dispatcher = createUnoService("com.sun.star.frame.DispatchHelper") dispatcher.executeDispatch(document,".uno:RestoreEditingView","",0,Array()) End Sub .uno:RestoreEditingView = Shift+F5 2 - Assign this macro to Open Document event : Tools/Customize Events Tab and save in LibreOffice (not the document) Seems to be OK with LibreOffice 7.4.6.2 under windows 11 and LibreOffice 24.2.0.3 under Ubuntu 20.4, with big document (2500 pages). The instruction with pagecount seems to be useless but if you comment it, the cursor is'nt to the right place
This same bug is still present in Version 24.2.0.3 (X86_64)
I didn't even know that LO Writer had this feature until Tip of the Day #105 appeared: > Your Writer document does not reopen with the text cursor at the same editing > position it was when you saved it? Add First or Last name in > Tools ▸ Options ▸ %PRODUCTNAME ▸ User Data ▸ First/last name. (https://cgit.freedesktop.org/libreoffice/core/tree/cui/inc/tipoftheday.hrc#n160 ) and... it didn't work at all in LibreOffice Version: 24.2.2.2 (X86_64) Flatpak; the text cursor appeared at the top. The Shift-F5 trick did work and settings.xml did hold ViewTop and ViewLeft, so I think I'm confirming this bug and not bug 140147. Please remove Tip of the Day #105 until it's reliable, or add "then press Shift-F5" to it.