When opening a larger document in Writer the last position of the cursor is not saved - instead of opening the last edited page of the document a random page is shown - rather erratically, I have to say (it's not always the same page!). This happens with an old config file (from 7.04) but also with a new pristine config-file.
Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Note that the attachment will be public, remove any sensitive information before attaching it. See the QA FAQ Wiki for further detail.)
In Tools - Options - LIbreOffice - User Data: fill a name under First/Last name. Save and test with your document again. Waiting for your tests results.
all done (filling User Data) - even reset properties of document - with the same result.
If you don't have many extensions there installed, could try a user reset profile: - Help - Restart in Safe Mode - Factory Settings check taht 2 options - and fill again user data... Waiting for your test again.
Created attachment 169498 [details] example odt file with wrong cursor placement after reloading file as I said before - starting with an pristine profile doesn't change anything. After reinstalling Libreoffice 7.1 I got the following peculiar behaviour: after restarting a document Writer loads the last edited page but the cursors stays at a different page. See attached file: after editing page 4, for example, Writer loads page 4 - as it should be - but the cursors stays at page 3 or 2.
It's ok on Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: ro-RO (ro_RO); UI: en-US Calc: threaded I will test this on linux tonight.
Confirm, it is not moving where the last save was. Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: en-US (ro_RO.UTF-8); UI: en-US Calc: threaded
Created attachment 169509 [details] video video showing the 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. ***
The bug is in still present in LO 7.1.1 too. Can be fixed for 7.1.2 release?
Do you think to assign this bug to a developer? Or to fix this bug in the next release? Just to know when I could switch from 7.0.x to 7.1.x
Bug seems to be fixed in 7.1.2 - Writer at least is working as expected & last position of cursor is saved
When is 7.1.2 to be released? My install is 7.1.1 and says it is up to date.
7.1.2 was released last week. Please install and try to rerpoduce the bug. See here: https://www.libreoffice.org/download/download/
I'm afraid that the way how the restoring of the position is implemented (using ViewLeft and ViewTop from settings.xml, which define a coordinate on "paper", not a position in text) would not allow to "fix" this: if the re-layout of the document has not yet been finished (which takes quite some time in a large document), SwView::ReadUserDataSequence would use some intermediate state of the document layout, and thus would position you to a random place in the document.
Oh, great! Why cannot be fixed? You could use a thread and when the document is all re-layouted you move the cursor to the correct point or simply revert the 7.1.x code to the 7.0.x version.
(In reply to Giovanni from comment #18) > You could use a thread and when the document > is all re-layouted you move the cursor to the correct point This doesn't make sense. Re-layout takes sometimes tens of seconds, and users would be upset having the document opened at start, then would start something they want to do, and then would get upset once again after some time being thrown to the last position when they already started doing something else. > or simply revert the 7.1.x code to the 7.0.x version. ... which would not help. The problem was always there since OOo 2.0, when the feature was implemented. It just appears in different documents depending on which document happen to layout slightly slower or faster in current version.
> The problem was always there since OOo 2.0, when the feature was implemented. > It just appears in different documents depending on which document happen to > layout slightly slower or faster in current version. Well, I never experienced that before 7.1... The thing is that something did change because it used to work fine. Or at least what you're talking about would appear in rare cases only.
(In reply to Hagar Delest from comment #20) About half of results of this search: https://www.google.com/search?hl=en&q=last%20position%20site%3Aask.libreoffice.org contains some comments mentioning "I entered the user info ... it still doesn't work ... it jumps to random place ..." for 6.2, 6.1, 4.4, some unspecified version from 2013, ... (I stopped checking) And something changed in 7.1.2, so that the problem is again hidden under the carpet.
I don't deny the code was not robust enough for all cases. BUT it did NOT happen to me until I tried 7.1 (and I use LO 8 hours a day). I reverted to 7.0 and it's OK again. So, perhaps there is a glitch but something did exacerbate the glitch so that it DOES occur 100% since 7.1. If you don't want to admit it, no problem, I'll redirect any question about that issue to this very bug report. When the evidence piles up, maybe someone will listen.
(In reply to Hagar Delest from comment #22) Do you say that the "fix" declared in version 7.1.2 in comment 14 doesn't work for you? If so, it just confirms what I wrote: that it only works by accident, and is easily broken by unrelated changes, just because it's fragile. Or do you say that you can't read, and start a meaningless flame, when I tell "it needs a proper fix finally" and you reply "no we need a fix, there's a problem, I don't listen, you won't admit, I tell everybody!!!1111
"This doesn't make sense. Re-layout takes sometimes tens of seconds, and users would be upset having the document opened at start, then would start something they want to do, and then would get upset once again after some time being thrown to the last position when they already started doing something else." It has sense because if I need a re-layout to work correctly on the document you can't work on it before it's been completed and you need to work on the last line you were working on if you're a writer. I remember once (I do not remember what version it was) LO on my Centrino CPU it was very slow to open a big ODT file and re-layout. Than, saying fast or slow depends on the CPU you have. But I have an Intel(R) Core(TM) i5-2430M CPU @ 2.40GHz with 4 GBytes of RAM and a Mac with an i5 and 16 GBytes of RAM and I have this bug on 7.1.x but not on 7.0.x so something is not clear why on the same CPU the 7.0.x performance is better than the one on the 7.1.x if you say nothing has been changed.
You can open a progress bar in a dialog to avoid user start typing or something similar. Something that can be closed if I'm in a hurry and I need to type where I want.
(In reply to Giovanni from comment #24) The correct fix is not all that complexity that introduces some blocking things like dialogs, or anything like that. It is *not* correct; some people may want to wait, some not; some are OK with intrusive things that break their interaction with applications, most hate those. "you need to work on the last line you were working on if you're a writer" is also just not correct *generally*, since author is not just something that is bound to continue typing (authors do many kinds of things with their documents, like formatting or revisiting different parts of text, however unexpected that could seem to some). The correct fix would be to store the last position not in terms of "position on page", but "position in text" ("this paragraph, this position between these two characters"), so that positioning cursor could be unambiguous and not dependent on the possibly slow operation. > something is not clear why on the same CPU the 7.0.x performance is better than the one on the 7.1.x if you say nothing has been changed 1. I didn't say *nothing* has been changed. I only said nothing has changed in the code that positions the cursor (which is unreliable). It indeed was a change that made other *unrelated* code different; and again: comment 14 tells that it has been changed again to mitigate the worse results in earlier 7.1 releases - is it not correct? 2. CPU only defined the speed of single operation, but the amount of operations depends on many things, and e.g. starting to take new features into account in a newer version might indeed introduce additional processing -> slower operation on the same HW.
"since author is not just something that is bound to continue typing (authors do many kinds of things with their documents, like formatting or revisiting different parts of text, however unexpected that could seem to some)." Not true. Depends. If you writer (I speak for me) changed and fixed more times a chapter and you just started a new chapter the last time you saved you need to go on from that point and not let the Editor pointing you 30 pages before. Anyway if "The correct fix would be to store the last position not in terms of "position on page", but "position in text" ("this paragraph, this position between these two characters"), so that positioning cursor could be unambiguous and not dependent on the possibly slow operation." I hope someone is going to apply this fix. And if this fix has been already applied someone should close this bug marking it as FIXED.
(In reply to Mike Kaganski from comment #19) > This doesn't make sense. Re-layout takes sometimes tens of seconds, and > users would be upset having the document opened at start, then would start > something they want to do, and then would get upset once again after some > time being thrown to the last position when they already started doing > something else. Just as some context for this discussion, the way MS Word solves this particular problem is that when the file is opened, it always displays the first page. Then, when it's ready, it shows a little bookmark icon in the bottom right corner. If the user chooses to click on that icon, it restores the cursor to its previous position.
(In reply to Michael Warner from comment #28) > the way MS Word solves this particular problem Sigh. No, MS Word does *not* have *this particular problem* at all. See tdf#112740, which describes how MS Word stores the position (notorious "_GoBack" bookmark), which does *not* depend on any such issues, and their method is just how they decided to implement the feature to allow user to choose to jump or not to jump, unrelated to *this particular problem*. > is that when the file is opened, it always displays the > first page. Then, when it's ready As described, this is not "when ready". >, it shows a little bookmark icon in the > bottom right corner. If the user chooses to click on that icon, it restores > the cursor to its previous position. ... which would still fail in Writer - see tdf#141586.
When I said "this particular problem" what I meant was the user experience problem of being able to choose whether or not to go back to the previously edited position, and when to present that option. I was not referring to the specific technical implementation details of how Writer and Word store the previously edited position, which are different, as you have noted.
*** Bug 142768 has been marked as a duplicate of this bug. ***
seems this bug reoccurs in 7.3.0.3 (here on KDE Neon) - last cursor position is not saved - arbitrary cursor placement in newly opened document. whether with new or old profile, doesn't matter - same behaviour.
Here too. LibreOffice 7.3 is bugged again. Using it on ArchLinux and Manjaro Linux with Xfce 64 bits. All packages updated at the current date.
I was asked to investigate this via bibisecting, but the problem is seen in the whole 7.1 and 7.2 Linux bibisect repos. Unless someone can give me an exact commit hash where it worked, I can't look into it.
Sorry - can't give you any commit hash. I just can say that in 7.2.5 (and previous versions since 7.1.2) this problem didn't exist.
Hi. I've also noticed this problem as of LibreOffice 7.3.2.2
I am also experiencing this problem in LibreOffice 7.3.2.2.
same problem here with 7.3.2.2, the problem occurs when you exceed about 40 pages
It's present again in the branch 7.3. In the version 7.3.5.2
Before you change the version field again, read its description: "Version: (earliest affected)"
Well, considering that this bug is 18 months old it's not going to be fixed, IMHO. It's in all 7.3 LibreOffice versions, also the new one 7.4. And now it's been introduced also into the version 7.2.7.2 too when 7.2.6 was not bugged. I use Writer everyday.
*** This bug has been marked as a duplicate of bug 141586 ***
I would like to add my experience to this thread. Note: I have tried the suggested solutions to this problem, without effect. • 19 Aug 2022 upgraded Libre Office 7.3.5.2 (x64) to 7.4.0.3 (x64) 21 Aug 2022 Noticed that this version does not properly remember where in the document the file was closed, so that when opened, the cursor is positioned somewhere quite remote from where it should be. Libre Office also opens in a fixed wide and shallow height window (that is, it does not remember the window size from the last close). • 18 Sep 2022 Upgraded Libre Office 7.4.0.3 (x64) to 7.4.1.2 (x64). This has fixed the opening size of the Libre Office window which was a problem from the 19 Aug 2022 7.4.0.3 (x64) upgrade. That is, the size when last closed is remembered again, but the position in the document is still not recalled. • 22 Oct 2022 Upgraded Libre Office 7.4.1.1 (x64) to 7.4.2.2 (x64). This has NOT FIXED the correct saving of the position in the document which has been a problem from the 19 Aug 2022 7.4.0.3 (x64) upgrade. • 15 Dec 2022 Upgraded Libre Office 7.4.2.3 to 7.4.3.2 (x64). This has NOT FIXED the correct saving of the position in the document which has been a problem from the 19 Aug 2022 7.4.0.3 (x64) upgrade. • 28 Jan 2023 Upgraded Libre Office 7.4.3.2 (x64) to: Version: 7.4.5.1 (x64) / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-NZ (en_NZ); UI: en-US Calc: threaded This has still NOT FIXED the correct saving of the position in the document which has been a problem from the 19 Aug 2022 7.4.0.3 (x64) upgrade. • 04 Feb 2023 Upgraded Libre Office Version: 7.4.5.1 (x64) to: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-NZ (en_NZ); UI: en-US Calc: threaded This has still NOT FIXED the correct saving of the position in the document which has been a problem from the 19 Aug 2022 7.4.0.3 (x64) upgrade. ----------------------------------------------------------------
This bug it's never going to be fixed so it think you should close it adding the note: "we don't want to fix it". Period. And that's why I stopped to donate to the project for each new release.
I've got bibisect results, it was a wild ride. Let's reopen this strictly on the regression part, for the general problem see bug 141586. Used these steps: - set first and last name in Options... / User Data, - open attachment 182077 [details] from bug 146988, - navigate to the end, type a character, save and reload. -> Somewhere the middle of the document is shown instead of the end of the document. This first started happening since the following commit in 7.1: https://cgit.freedesktop.org/libreoffice/core/commit/?id=c0864f26f3143ea81c65d3826fae32a8fd54c531 author Michael Stahl <Michael.Stahl@cib.de> 2020-11-06 21:47:21 +0100 committer Michael Stahl <michael.stahl@cib.de> 2020-11-19 14:21:10 +0100 "sw_fieldmarkhide: init fieldmark mode from options" The commit was later reverted both in 7.2 and 7.1, that's when the bug seemed fixed: https://cgit.freedesktop.org/libreoffice/core/commit/?id=70dd95aabd11b2146e2556c1da87da4a22d6f7b5 - 7.2 author Michael Stahl <michael.stahl@allotropia.de> 2021-03-01 12:47:53 +0100 committer Michael Stahl <michael.stahl@allotropia.de> 2021-03-02 09:53:49 +0100 https://cgit.freedesktop.org/libreoffice/core/commit/?id=9bc548e1c7da69c3f886b5925df3df4f78cd6239 - 7.1 author Michael Stahl <michael.stahl@allotropia.de> 2021-03-01 12:47:53 +0100 committer Xisco Fauli <xiscofauli@libreoffice.org> 2021-03-02 13:08:43 +0100 "Revert "sw_fieldmarkhide: init fieldmark mode from options" " Then the revert was reverted (ie. the commit was back in again) in 7.4 and 7.3: https://cgit.freedesktop.org/libreoffice/core/commit/?id=657de5fba12b0e9afcdee361654d2a2d0dbd7311 - 7.4 author Michael Stahl <michael.stahl@allotropia.de> 2021-11-19 16:08:57 +0100 committer Michael Stahl <michael.stahl@allotropia.de> 2021-12-23 09:11:59 +0100 https://cgit.freedesktop.org/libreoffice/core/commit/?id=6433dc223f6d21570e7132c4a580d186a5d5a334 - 7.3 author Michael Stahl <michael.stahl@allotropia.de> 2021-11-19 16:08:57 +0100 committer Thorsten Behrens <thorsten.behrens@allotropia.de> 2021-12-23 12:08:38 +0100 "Revert "Revert "sw_fieldmarkhide: init fieldmark mode from options"" " Adding CC: to Michael Stahl.
*** Bug 153263 has been marked as a duplicate of this bug. ***
*** Bug 153113 has been marked as a duplicate of this bug. ***
*** Bug 150114 has been marked as a duplicate of this bug. ***
*** Bug 151427 has been marked as a duplicate of this bug. ***
*** Bug 152097 has been marked as a duplicate of this bug. ***
*** Bug 150787 has been marked as a duplicate of this bug. ***
*** Bug 152328 has been marked as a duplicate of this bug. ***
*** Bug 148785 has been marked as a duplicate of this bug. ***
*** Bug 148368 has been marked as a duplicate of this bug. ***
This remains unfixed in LO 7.5: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 32; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Last I saw this was supposed to be fixed in 7.5 and it is not. See bug 146998 for examples attached to reproduce the problem.
(In reply to MR Zenwiz from comment #60) > Last I saw this was supposed to be fixed in 7.5 and it is not. This bug being open means the issue isn't supposed to be fixed in 7.5.0. A problem was identified and fixed in bug 146988, but it apparently wasn't the same.
Using LibreOffice 7.5.2.2 on Arch Linux, the behavior is still the same (or at least very similar) as in the attached video uploaded by BogdanB. I'd just like to add two observations: 1) The position when opening the document does not seem to be random; in my case, currently working on a document with ~ 20 pages, the position of the cursor after the document is opened seems to be relative to the actual last cursor position when it was last saved, around 5 pages before (this could be proportional to the document size, e.g., in the video it is positioned on page 2 instead of page 4). I didn't verify that this is fully deterministic or check if the relative offset is always (proportionally or absolutely) the same, but if no changes are made to the document, the cursor is positioned the same as on the previous opening. 2) Shift+F5 (=move the cursor to the last saved position) works, which means that the last cursor position is saved, it's just not applied correctly when opening the document, instead, the cursor is positioned with a certain offset, as described in the previous paragraph.
Shift+F5 is a saviour for now. Thanks.
*** Bug 155781 has been marked as a duplicate of this bug. ***
*** Bug 155824 has been marked as a duplicate of this bug. ***
Unfortunately the bug is still present in the latest version of LO Fresh 7.5.5.2.
The bug persists also in the latest version of LO Fresh 7.6.0.3. Is there any prospect that the issue will be solved?
No change: the bug persists also in the latest version of LibreOffice Fresh 7.6.1.2.
present in Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 4; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded
Un-CCing developer, its unclear if we can find the time to look into it at this stage.
*** Bug 152098 has been marked as a duplicate of this bug. ***
I always want to find out the mystery that that's not my neighbor always wants players to discover. Please join me at https://thatsnot-myneighbor.com to find out this secret.
present in Version: 24.2.5.2 (X86_64) / LibreOffice Community Build ID: bffef4ea93e59bebbeaf7f431bb02b1a39ee8a59 CPU threads: 4; OS: Linux 6.7; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded
This is not only still present in 24.2.5.2, it is worse. At least in previous revisions (up through the last 7.* release) the document used to open in a random location not far from the previous last edited position. This is annoying, but it was consistent. Now, regardless of document size, Writer always opens at the beginning of the .odt (or .docx) and there is no convenient way to return to the "last edited" position - a nice feature that is standard in MS Word. How long is it going to take to fix this? It has 70+ comments going back over 3 years, most of which confirm the bug.
(In reply to MR Zenwiz from comment #74) > This is not only still present in 24.2.5.2, it is worse. > > At least in previous revisions (up through the last 7.* release) the > document used to open in a random location not far from the previous last > edited position. This is annoying, but it was consistent. > > Now, regardless of document size, Writer always opens at the beginning of > the .odt (or .docx) and there is no convenient way to return to the "last > edited" position - a nice feature that is standard in MS Word. > > How long is it going to take to fix this? It has 70+ comments going back > over 3 years, most of which confirm the bug. I have similar experience, however, the file opens more often than not on a page I was last editing, but the cursor is somewhere else. OR, the file opens to some location that I have not visited for some time, repeatedly. There is no consistency. I add my disgruntlement to that of MR Zenwiz. WHEN will this be fixed?
(In reply to MR Zenwiz from comment #74) > This is not only still present in 24.2.5.2, it is worse. > > At least in previous revisions (up through the last 7.* release) the > document used to open in a random location not far from the previous last > edited position. This is annoying, but it was consistent. > > Now, regardless of document size, Writer always opens at the beginning of > the .odt (or .docx) and there is no convenient way to return to the "last > edited" position - a nice feature that is standard in MS Word. Not reproduced. Following the steps from comment 46 I end up on page 39, *not* at the beginning of the document. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 028ae168ca787e5c92560d051009a0f115911b57 CPU threads: 8; OS: Linux 6.10; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
(In reply to Buovjaga from comment #76) > (In reply to MR Zenwiz from comment #74) No degredation, likewise to @Buovjaga but on Win10 Version: 24.2.5.1 (X86_64) / LibreOffice Community Build ID: 2ccb78ad6bdfe3f3356a7a7f294ec388775c5816 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 24.8.0.3 (X86_64) / LibreOffice Community Build ID: 0bdf1299c94fe897b119f97f3c613e9dca6be583 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c52f139b4f7140033144dde29f70a39ebedb6aa0 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Follow STR of comment 46. With a Tools -> Options -> User Data entry made, make a new edit at end of document. Save and reopen--edit cursor mispositioned in document at page 39. While a <Shift>+F5 still does correctly reposition to last edit position at End of document.
Created attachment 196262 [details] Sample document in .docx formet
Created attachment 196263 [details] Sample document in .odt formet
(In reply to MR Zenwiz from comment #78) > Created attachment 196262 [details] > Sample document in .docx formet It does jump to page 1 in that document, but it does that already in 7.1, so there is no degradation.
(In reply to Buovjaga from comment #80) In LibreOffice (and in OpenOffice), there was *never* a feature of restoring the editing position *in foreign documents*. DOCX is completely unrelated to the issue discussed here.
(In reply to Mike Kaganski from comment #81) > (In reply to Buovjaga from comment #80) > > In LibreOffice (and in OpenOffice), there was *never* a feature of restoring > the editing position *in foreign documents*. DOCX is completely unrelated to > the issue discussed here. Indeed!! With the foreign influence eliminated, the position saving glitch behaves as intended, teleporting me to page 47 in the ODT.
(In reply to Buovjaga from comment #82) "position saving glitch behaves as intended" Suspect you meant "as reported". Same here with attachment 196263 [details], and then on edit-save-reopen from mispositioned view port a <Shift>+F5 continues to reposition edit cursor view port to at least same line as the actual 'last edit'
(In reply to V Stuart Foote from comment #83) > (In reply to Buovjaga from comment #82) > > "position saving glitch behaves as intended" > > Suspect you meant "as reported". Same here with attachment 196263 [details] > [details], and then on edit-save-reopen from mispositioned view port a > <Shift>+F5 continues to reposition edit cursor view port to at least same > line as the actual 'last edit' I guess your Ivory Tower approach trumps all other considerations. The ODF document standards are terrific and consistent. I applaud that and agree. However, the MSO documents overwhelmingly continue to dominate the real world of office documents. Thiss will probably remain true until the world recognizes that MS<anything> is trash and needs to be discarded in favr of something safe, reliable and resilient (aka, Linux, which does not run MS<anything> without outside assistance (e.g., Wine). The very least that LO should do is document clearly and plainly that LO is not MSO compatible, never will be, and why (standardized formats vs inconsistent proprietary junk formats that most people continue to use). I withdraw my objections, complaints and bugs.