Bug 129167 - Last position restore no longer working
Summary: Last position restore no longer working
Status: RESOLVED DUPLICATE of bug 112740
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.3.3.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-03 21:56 UTC by Roland Hughes
Modified: 2022-06-29 11:23 UTC (History)
4 users (show)

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


Attachments
Name info was filled in both before and after upgrade (62.84 KB, image/png)
2019-12-04 19:15 UTC, Roland Hughes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roland Hughes 2019-12-03 21:56:28 UTC
Description:
Prior to updating to 6.3.3.2 whenever I reopened a book I was working on the cursor would automatically reposition to its last place. This no longer happens and the keyboard shortcut no longer works. Yes, I have my user data information filled in. This was working until I was told to upgrade when tracking down another bug.

Steps to Reproduce:
1.Take a 400+ page document
2.Edit something around 200 pages in, save, exit LO
3.Right click on the document file and select open in LO



Actual Results:
Document opens and you are back at the very tippy top

Expected Results:
Document should load and cursor should return to its last position in the document.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
The keyboard shortcut doesn't even work.

roland@roland-HP-EliteDesk-800-G2-SFF:~$ glxinfo | grep OpenGL
OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce GT 630/PCIe/SSE2
OpenGL core profile version string: 4.6.0 NVIDIA 390.116
OpenGL core profile shading language version string: 4.60 NVIDIA
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6.0 NVIDIA 390.116
OpenGL shading language version string: 4.60 NVIDIA
OpenGL context flags: (none)
OpenGL profile mask: (none)
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 NVIDIA 390.116
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
roland@roland-HP-EliteDesk-800-G2-SFF:~$
Comment 1 BogdanB 2019-12-04 19:10:24 UTC
It is not a bug. You need to enter your name into Tools - Options - LibreOffice - User data and here enter at least first name or last name.

Please answer to know that you solved this.
Comment 2 Roland Hughes 2019-12-04 19:15:08 UTC
Created attachment 156309 [details]
Name info was filled in both before and after upgrade

It's a bug. My name information was filled in both before and after the upgrade from PPA. See image. Last position saving always worked before hand, doesn't work at all now.
Comment 3 Roland Hughes 2019-12-04 19:19:11 UTC
Just conducted another test. The restoring of last position used to work with both docx and odt. Now it appears to only be working with odt. Maybe it wasn't supposed to work with docx, but it did.
Comment 4 BogdanB 2019-12-04 19:34:21 UTC
Confirm your bug. Working with .odt but not with the same document saved as .docx

NOT WORKING ON 
Version: 6.3.3.2
Build ID: a64200df03143b798afd1ec74a12ab50359878ed
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US
Calc: threaded
Comment 5 Roland Hughes 2019-12-04 19:37:12 UTC Comment hidden (no-value)
Comment 6 Timur 2019-12-11 11:35:18 UTC
This is a duplicate. 
For opening DOCX saved in MSO there's bug 112742. 
And for saving bug 112740.
I guess this refers to saving, but 112742 must be solved first.

*** This bug has been marked as a duplicate of bug 112740 ***
Comment 7 Timur 2019-12-11 11:36:02 UTC Comment hidden (obsolete)
Comment 8 BogdanB 2019-12-11 12:00:31 UTC Comment hidden (obsolete)
Comment 9 Roland Hughes 2019-12-11 12:24:14 UTC Comment hidden (obsolete)
Comment 10 Justin L 2022-06-22 17:34:42 UTC
Did this really work at some point for DOCX format? I could not reproduce it working in 5.2 or 4.1.
Comment 11 Roland Hughes 2022-06-22 18:21:39 UTC
(In reply to Justin L from comment #10)
> Did this really work at some point for DOCX format? I could not reproduce it
> working in 5.2 or 4.1.

Yes it did. You had to have the contact information filled all the way out though.

This isn't really a duplicate of bug 112740 though it has been marked as such.

Saving a bookmark in the file itself would mean one could copy the file to any other machine with LO and have it open to the same line/col position. As far as I know that never worked.

I believe the information/position was saved somewhere in a .conf/ or .local/ tree under Linux. You had to have that contact info filled all the way out though.

So, this isn't resolved. Having said that I got soooo frustrated with LO over this and other instabilities that I purchased SoftMaker's TextMaker for all my machines. Haven't used LO since some time in 2020 I believe. Just too unstable.
Comment 12 Mike Kaganski 2022-06-25 07:41:56 UTC
(In reply to Roland Hughes from comment #11)
> (In reply to Justin L from comment #10)
> > Did this really work at some point for DOCX format? I could not reproduce it
> > working in 5.2 or 4.1.
> 
> Yes it did. You had to have the contact information filled all the way out
> though.

No it never worked in anything except ODT/FODT, neither in LibreOffice, nor in any other OOo derivative. You are mistaken.

> This isn't really a duplicate of bug 112740
> though it has been marked as such.

Yes it is. It asks to restore position in DOCX, as it does for ODT (comment 3). What you write in comment 11 (and in bug 112740 comment 6) is a *different* feature request - please file it separately. Thank you.
Comment 13 Roland Hughes 2022-06-25 07:55:23 UTC
(In reply to Mike Kaganski from comment #12)
> (In reply to Roland Hughes from comment #11)
> > (In reply to Justin L from comment #10)
> > > Did this really work at some point for DOCX format? I could not reproduce it
> > > working in 5.2 or 4.1.
> > 
> > Yes it did. You had to have the contact information filled all the way out
> > though.
> 
> No it never worked in anything except ODT/FODT, neither in LibreOffice, nor
> in any other OOo derivative. You are mistaken.

Mistake for the entire time it took me to write this book?
https://www.theminimumyouneedtoknow.com/soa_book.html

I think not.

> 
> > This isn't really a duplicate of bug 112740
> > though it has been marked as such.
> 
> Yes it is. It asks to restore position in DOCX, as it does for ODT (comment
> 3). What you write in comment 11 (and in bug 112740 comment 6) is a
> *different* feature request - please file it separately. Thank you.

No, it's not a *different* feature. I'm pointing out the train wreck short sighted development will create if they go down the route of saving the last user position as a bookmark in the file.

I've written a ___lot___ of books.

Not once have I had last user position survive moving a document between machines with any word processor on any OS.

Today's reality is that many different users will edit the exact same file from a NAS or DropBox type location. If you store the last position within the file itself you create a train wreck with "last one in wins" and you will create an avalanche of bug reports claiming the last position feature doesn't work because each user will get the last position of whoever was in the file last, not the last position from their last edit session on their machine.
Comment 14 Justin L 2022-06-25 14:54:29 UTC
I used last62onmaster to test this with LO 6.2, and couldn't reproduce.
I first filled in every field in Tools - Options - User Data. Then I saved a document as DOCX while on the second page. Re-opening the document started me at the beginning - not at the edit point. (Testing as ODT did re-open at the edit point).

When you can reliably reproduce thing on something like LO 6.x and then provide clear steps so that others can reproduce this bug, feel free to re-open it as NEW, and we should be able to track down what change broke automatic repositioning.
Comment 15 Mike Kaganski 2022-06-25 15:29:27 UTC
(In reply to Roland Hughes from comment #13)
> (In reply to Mike Kaganski from comment #12)
> 
> Mistake for the entire time it took me to write this book?
> 
> I think not.

It doesn't matter what you think. The restoration of the last position has a clear known history in OOo [1]. The code is open, and all changes are stored in the git history of the project; there was never code that would allow to restore position in any non-native file format. You could had used a native format (odt), or you could had used a third-party extension (I don't know such, but who knows), or you could have used MS Word. Memory is an unreliable thing. But again: there was never such a feature in LibreOffice. Period.

> > > This isn't really a duplicate of bug 112740
> > > though it has been marked as such.
> > 
> > Yes it is. It asks to restore position in DOCX, as it does for ODT (comment
> > 3). What you write in comment 11 (and in bug 112740 comment 6) is a
> > *different* feature request - please file it separately. Thank you.
> 
> No, it's not a *different* feature.

It *is*. Just because you mentioned that you know that you want to have for MS formats what is *already available* for odt. And for odt, the last position is stored in the document. And the only way to have the *same* feature in an external format is to follow that format's creator convention.

> I'm pointing out the train wreck ...

And here you are talking about the different thing, as I pointed out. You may have a point and a reasonable feature request - that is different from what you wrote here initially. And even if your proposal would be implemented, it doesn't make the feature that Justin is implementing "short-sighted" other than the short-sightedness of those who don't appreciate implementation of others' needed features. 

[1] See bug 141586, and discussion strating at bug 140147 comment 17.
Comment 16 Roland Hughes 2022-06-25 18:17:35 UTC
(In reply to Mike Kaganski from comment #15)
> (In reply to Roland Hughes from comment #13)
> > (In reply to Mike Kaganski from comment #12)
> > > > This isn't really a duplicate of bug 112740
> > > > though it has been marked as such.
> > > 
> > > Yes it is. It asks to restore position in DOCX, as it does for ODT (comment
> > > 3). What you write in comment 11 (and in bug 112740 comment 6) is a
> > > *different* feature request - please file it separately. Thank you.
> > 
> > No, it's not a *different* feature.
> 
> It *is*. Just because you mentioned that you know that you want to have for
> MS formats what is *already available* for odt. And for odt, the last
> position is stored in the document. And the only way to have the *same*
> feature in an external format is to follow that format's creator convention.

No, it's not the **only** way. I've written software for 30 (almost 40) years. Believing that there will be only a single editor of a document in 2022 and storing last position in the document itself isn't the **only** way, in fact it is a really bad way because last one in wins.

> implemented, it doesn't make the feature that Justin is implementing
> "short-sighted" other than the short-sightedness of those who don't
> appreciate implementation of others' needed features. 

I fully understand "others' needed features." My software goes into medical devices and has for the past 10 years or so. In all honesty I hope to never have to have any of them used on me, not because I doubt my work, I just don't ever want to be sick enough to need a patient monitor, infusion pump, etc.

Implementing "last one in wins" is short sighted and an architectural flaw. In today's world, especially the business world, there will be at least two, usually around six, people who work on any given document. They will all want their environment to come up to the last place they were.
Comment 17 Mike Kaganski 2022-06-25 21:00:01 UTC
(In reply to Roland Hughes from comment #16)

Sigh.
1. Roland Hughes writes in comment 0:

> Prior to updating to 6.3.3.2 whenever I reopened a book I was working on the
> cursor would automatically reposition to its last place. This no longer happens
> and the keyboard shortcut no longer works.

We read a regression report here; so indeed, what is requested is to restore *what was already working*.

2. Roland Hughes writes in comment 3:

> The restoring of last position used to work with both docx and odt. Now it
> appears to only be working with odt.

We read here, that Roland Hughes wants their docx behave like odt. Regardless of the "it used to work with docx" delusion, the request is not "make something different".

Now take a look at the LibreOffice code, where it restores the last position, and learn that it is implemented (from the start) to store that information in the ODT. Using a very simple logic, the request in this bug 129167 is exactly "implement storing last position inside docx".

And yes, since the format is a MS format, we can't just start extending it randomly without any need, we should stick to what MS used to store sch a position.

3. Roland Hughes writes in comment 11:

> Saving a bookmark in the file itself would mean one could copy the file to any
> other machine with LO and have it open to the same line/col position.

The already mentioned delusion surfaces again. There was never anything like what Roland Hughes describes *in LibreOffice* (or in any other OOo derivative). So obviously, Roland Hughes *intended* to ask something different from what they *actually* asked. So *this* report was created in a wrong way, and was misleading from the start; in its current form, it is *exactly* duplicate of bug 112740, while what Roland Hughes intended to request needs to be filed separately (just because trying to rectify the initial mistake would not make the request clear - it's best to start from scratch).

4. Roland Hughes writes in comment 16:

> Implementing "last one in wins" is short sighted and an architectural flaw.

Here they show how little they try to think about different needs. They think about working in teams on the same file (a reasonable use case, even though there is a different solution exist for that case, like Collabora Online, but still having something "local" for that might be still reasonable); but they just don't even ask "what is the use case for that feature that we declare short sighted", they simply go ahead and declare. Well, of course, being able to pick up working on *my* document at the point where I left, *regardless* of which device I use at this moment (and thus, regardless of which user profile I use at this moment) has no value for anyone, they perfectly know that.

MS may abandon their approach of storing the last position using the bookmark - because they simply move to the cloud, and the last position may be restored wherever you open the document. But LibreOffice has no central cloud. It is not intended to push users to cloud. And thus, the storing of the last position in the document is perfectly reasonable for a large portion of the user base, and that doesn't exclude a potential option for a user to choose where to store that - *if* Roland Hughes decides to file their feature request properly.
Comment 18 Roland Hughes 2022-06-28 16:30:31 UTC
(In reply to Mike Kaganski from comment #17)
> (In reply to Roland Hughes from comment #16)
> 

Sigh.
> 
> Now take a look at the LibreOffice code, where it restores the last
> position, and learn that it is implemented (from the start) to store that
> information in the ODT. Using a very simple logic, the request in this bug
> 129167 is exactly "implement storing last position inside docx".
> 
> And yes, since the format is a MS format, we can't just start extending it
> randomly without any need, we should stick to what MS used to store sch a
> position.
> 
> 
> Here they show how little they try to think about different needs. They
> think about working in teams on the same file (a reasonable use case, even
> though there is a different solution exist for that case, like Collabora
> Online, but still having something "local" for that might be still
> reasonable); but they just don't even ask "what is the use case for that
> feature that we declare short sighted", they simply go ahead and declare.
> Well, of course, being able to pick up working on *my* document at the point
> where I left, *regardless* of which device I use at this moment (and thus,
> regardless of which user profile I use at this moment) has no value for
> anyone, they perfectly know that.
> 
> MS may abandon their approach of storing the last position using the
> bookmark - because they simply move to the cloud, and the last position may
> be restored wherever you open the document. But LibreOffice has no central
> cloud. It is not intended to push users to cloud. And thus, the storing of
> the last position in the document is perfectly reasonable for a large
> portion of the user base, and that doesn't exclude a potential option for a
> user to choose where to store that - *if* Roland Hughes decides to file
> their feature request properly.

Extreme sigh.

Here we see the grand delusion that storing last position inside a document file wasn't a massive architectural flaw from the beginning. Then we try to champion a use case (the only use case that wasn't thrown under the bus by this implementation) to justify a short sighted architectural decision. Then we spin a yarn about MS and cloud being the reason they ceased using the same architectural flaw.

MS stopped using almost instantaneously after writing into the spec saving last position inside a document file. It was a flawed architectural design. It had nothing to do with the cloud. It had to do with Netware file servers and later Linux and Microsoft file servers. Storing inside of the document was a "last one in wins" __solutions__ that failed in a world where more than C: existed for a computer. It failed spectacularly when multiple users accounts were set up on the same physical computer using a shared data drive/partition.

Once MS has published a file spec it cannot really be "fixed." Generally large portions get deprecated and go unused.

Generally all editing systems, not just word processors, but IDEs and even some graphics editors solve this problem in at least one of (sometimes 2+ of) the following ways.

1.) Extended Attributes

We started using these back in the days of OS/2. They are supported by every major file system today though not always supported in the same way. When you use the OS level utilities to copy the file to another drive/partition the extended attributes are copied with it. You can have user.name EA.

user.Fred.LastPosition:45;3456;98765956;

Been a long time since I chatted with anyone working internally on such things at MS. I believe that is how they are doing it yet today. There is a size limit which might be why there are only 4 <Shift><F5>

https://legalofficeguru.com/pick-up-where-you-left-off-in-microsoft-word-with-go-back/

https://en.wikipedia.org/wiki/Extended_file_attributes
https://hexdocs.pm/xattr/Xattr.html
https://www.admin-magazine.com/HPC/Articles/Extended-File-Attributes
https://www.delftstack.com/howto/c/getxattr-example-in-c/

Extended attributes in user.name.LastPosition: format allow every application to know what the last position was for each user to ever touch the file.

The EA solution is only a "last one in wins" solution if it is poorly implemented as:

user.LastPosition:4567;34987;1;32767

where it would not identify the user.

2) Application level settings file

Every major cross platform library has some form of "Settings" class that does the heavy lifting of communicating with the OS to create/read/store application settings. They are stored at the user level. You've all seen .config and .local directories in your home directory under Linux. Windows tends to jamb the stuff into Registry.

During the days of DOS (which includes all versions of Windows prior to Windows NT because Windows was not an OS until NT) vendors kind of rolled their own. We only had one user though. Things were really rough in early Linux days. MS Word was released in 1983 on DOS. Your Go-Back book mark is most likely an artifact of this era. It had to be abandoned once file servers entered IT departments.

3) Hidden or visible history file

Many were simply filename.hist Many times they were just one type of history so they were one line records like this:

timestamp|user|numeric_value

The timestamp was always in YYYYMMDD:HHmmss.cc format so sort order could be maintained. When they started getting complex they took on less efficient formats.

keytag|timestamp|user|numeric_or_text_value

This particular debacle morphed into extended attributes


For whatever reason ODT pursued a Go-Back bookmark which creates many problems and was abandoned late in the days of DOS.

When I said this was short sighted I was talking about the physical implementation. It through every other use case under the bus by using a bookmark instead of EA. With EA, every user's last N positions can be saved. The UI can then offer the option of using someone else's last position or the user's own.
Comment 19 Mike Kaganski 2022-06-28 19:59:45 UTC
It isn't even funny. All that bs just to pretend something might be possible under some strict controlled conditions. Like extended filesystem-level attributes or separate files, in face of heterogeneous environments like FAT-formatted memory sticks or shares that deny different file types based on random admin decisions like "no filenames beginning with dot".

Anyhow, at this point, it's just a waste of time to "discuss" anything with a person who kniws The Ultimate Truth. I'm done here, won't try to help you to make your proposal a proper Bugzilla issue anymore.
Comment 20 Roland Hughes 2022-06-29 11:23:48 UTC
(In reply to Mike Kaganski from comment #19)
> It isn't even funny. All that bs just to pretend something might be possible
> under some strict controlled conditions. Like extended filesystem-level
> attributes or separate files, in face of heterogeneous environments like
> FAT-formatted memory sticks or shares that deny different file types based
> on random admin decisions like "no filenames beginning with dot".
> 
> Anyhow, at this point, it's just a waste of time to "discuss" anything with
> a person who kniws The Ultimate Truth. I'm done here, won't try to help you
> to make your proposal a proper Bugzilla issue anymore.

You weren't "helping" to begin with and none of what I posted was bs. Thank you for leaving the discussion.