Bug 141586 - Restoring last document position is unreliable
Summary: Restoring last document position is unreliable
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: accessibility
: 140147 150114 150787 151427 152097 152328 (view as bug list)
Depends on:
Blocks: Saved-Cursor
  Show dependency treegraph
Reported: 2021-04-09 13:12 UTC by Mike Kaganski
Modified: 2022-11-30 23:20 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:
Regression By:

Screen cast of described unreliable last position restore function (1.60 MB, image/gif)
2021-04-09 14:13 UTC, Mike Kaganski

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2021-04-09 13:12:48 UTC
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.


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
Comment 1 Mike Kaganski 2021-04-09 14:13:48 UTC
Created attachment 171059 [details]
Screen cast of described unreliable last position restore function
Comment 2 V Stuart Foote 2021-04-10 16:59:15 UTC
@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? 


[1] https://opengrok.libreoffice.org/xref/core/sw/source/uibase/uiview/view.cxx?r=c0936ba2#1297
Comment 3 J.R. MITCHELL 2021-09-13 23:52:13 UTC
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 and it's doing it again. Before installing this version the older version 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?
Comment 4 Mike Kaganski 2022-07-23 17:25:16 UTC
*** Bug 150114 has been marked as a duplicate of this bug. ***
Comment 5 Mike Kaganski 2022-09-05 08:37:02 UTC
*** Bug 150787 has been marked as a duplicate of this bug. ***
Comment 6 Mike Kaganski 2022-11-18 06:23:52 UTC
*** Bug 152097 has been marked as a duplicate of this bug. ***
Comment 7 Hagar Delest 2022-11-18 07:19:52 UTC
*** Bug 140147 has been marked as a duplicate of this bug. ***
Comment 8 Hagar Delest 2022-11-18 07:26:19 UTC
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.
Comment 9 Hagar Delest 2022-11-18 07:27:50 UTC Comment hidden (obsolete)
Comment 10 Stéphane Guillou (stragu) 2022-11-18 16:10:11 UTC
Marking as NEW given the number of duplicates.
Comment 11 Stéphane Guillou (stragu) 2022-11-18 16:10:18 UTC
*** Bug 151427 has been marked as a duplicate of this bug. ***
Comment 12 Buovjaga 2022-11-30 23:20:36 UTC
*** Bug 152328 has been marked as a duplicate of this bug. ***