Bug 51821 - Writer only sometimes remember last editing position
Summary: Writer only sometimes remember last editing position
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.5.2 release
Hardware: All All
: low trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 50319 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-07-07 01:24 UTC by Andrej
Modified: 2021-06-03 15:13 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
File that remembered last editing position (10.71 KB, application/vnd.oasis.opendocument.text)
2012-07-07 01:24 UTC, Andrej
Details
File that does not remembered last editing position (9.76 KB, application/vnd.oasis.opendocument.text)
2012-07-07 01:25 UTC, Andrej
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andrej 2012-07-07 01:24:33 UTC
Created attachment 63923 [details]
File that remembered last editing position

Writer only sometimes remembers and restores the last editing position.

I have two examples attached. The no file, does not remember the 
last position, but the yes file does. 

open "no.odt"
after editing, position a cursor at the end of the word four
close and save


open "yes.odt"
after editing, position a cursor in word Ana between n and a
close and save

Thank you for your time

Please note: 
I do have "User data" in  Tools  ->  Options...  ->  LibreOffice
Both files came from the same original file, at some point.
Bath files have "Web Layout". <- that is what I would like, please.
In "Print Layout", both file remembers the last position fine!
I have a version 3.5.2.2
Comment 1 Andrej 2012-07-07 01:25:58 UTC
Created attachment 63924 [details]
File that does not remembered last editing position
Comment 2 bfoman (inactive) 2013-01-28 12:08:23 UTC
(In reply to comment #0)
> Bath files have "Web Layout". <- that is what I would like, please.
> In "Print Layout", both file remembers the last position fine!

Checked with:
LO 4.0.0.2
Build ID: own W7 debug build
Windows 7 Professional SP1 64 bit

Cursor position was always on top for both files, in both views.
Comment 3 Andrej 2013-01-28 16:17:00 UTC
I have now version 3.6.2.2 (Build ID: da8c1e6) and seems to work fine.
I will close this bug.

Thank you
Comment 4 Pierre-Alain Dorange 2013-05-13 08:57:57 UTC
Do not works with 4.0 branch.
In all ODT i checked the last edited position was not restored when file are (re)open.
All ODT file open are positionned on top.

Very annoying with long documents.
Comment 5 Pierre-Alain Dorange 2014-01-28 10:38:57 UTC
Works (branch 4.x) only if the user fill-in its personnal info in the preferences panel, otherwise the position are not remembered.
I do not really understand why -, but it was a strange behavior.

I think that even if the user do not fill "personnal data" the last position lust be remembered...
Comment 6 Joel Madero 2014-11-06 03:11:17 UTC
Version is oldest version that the bug was seen, not the newest. Changing back.

Needs to be confirmed by QA so moving this back to UNCONFIRMED -> thanks.
Comment 7 Buovjaga 2014-11-16 15:41:52 UTC
(In reply to andrej8anubis from comment #1)
> Created attachment 63924 [details]
> File that does not remembered last editing position

It doesn't remember the cursor position, even if I have stuff in my options - user data.

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@39, Branch:master, Time: 2014-11-12_01:10:08

Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+
Build ID: 3cf226622a3d8c09d655034dbcc81695f1662b87
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-15_23:24:22
Comment 8 Pierre-Alain Dorange 2015-02-24 15:27:50 UTC
The solution is simply to have user identification set in preferences.
It was a very simple solution, when we know it (it take me lot of time to found this). Perhaps a more easy way could be a good thing.
Comment 9 Buovjaga 2015-02-24 15:38:54 UTC
Oups :) ok I'll set this to INVALID as it's a better status in this case.
Comment 10 Buovjaga 2021-06-03 15:12:45 UTC
*** Bug 50319 has been marked as a duplicate of this bug. ***