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:~$
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.
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.
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.
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
(In reply to BogdanB from comment #4) > 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 Thank you. Most odd though. One would think the last position information would be stored with "recent" file list information. It shouldn't care about the file type. Once the file is loaded, jump to last position. Thanks again for confirmation.
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 ***
When reporting and confirming, most important is to first search, please do.
Ok, Timur, I will try.
(In reply to Timur from comment #7) > When reporting and confirming, most important is to first search, please do. I did search, but your search tool isn't very holistic. When I searched for "restore last cursor position" the bugs you flag this duplicate of weren't in the first screen of results. What it found wasn't even close. According to the "WordPro Tabbed Divisions" request conversation, the larger number of duplicates the higher the priority.
Did this really work at some point for DOCX format? I could not reproduce it working in 5.2 or 4.1.
(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.
(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.
(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.
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.
(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.
(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.
(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.
(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.
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.
(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.