Bug 140147 - Position of cursor not saved correctly (see comment 46 for bibisect)
Summary: Position of cursor not saved correctly (see comment 46 for bibisect)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.0.3 release
Hardware: All All
: high major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 140368 140860 141024 142768 148785 150114 150787 151427 152097 152328 153113 153263 155781 (view as bug list)
Depends on:
Blocks: Saved-Cursor
  Show dependency treegraph
 
Reported: 2021-02-04 10:54 UTC by cekilch
Modified: 2024-03-07 07:38 UTC (History)
23 users (show)

See Also:
Crash report or crash signature:


Attachments
example odt file with wrong cursor placement after reloading file (8.90 KB, application/vnd.oasis.opendocument.text)
2021-02-05 12:19 UTC, cekilch
Details
video (943.37 KB, video/mp4)
2021-02-05 18:33 UTC, BogdanB
Details

Note You need to log in before you can comment on or make changes to this bug.
Description cekilch 2021-02-04 10:54:07 UTC
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.
Comment 1 mulla.tasanim 2021-02-04 20:01:14 UTC
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.)
Comment 2 BogdanB 2021-02-04 21:01:11 UTC
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.
Comment 3 cekilch 2021-02-05 08:26:24 UTC
all done (filling User Data) - even reset properties of document - with the same result.
Comment 4 BogdanB 2021-02-05 09:19:55 UTC
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.
Comment 5 cekilch 2021-02-05 12:19:13 UTC
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.
Comment 6 BogdanB 2021-02-05 14:03:58 UTC Comment hidden (obsolete)
Comment 7 BogdanB 2021-02-05 18:30:45 UTC
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
Comment 8 BogdanB 2021-02-05 18:33:04 UTC
Created attachment 169509 [details]
video

video showing the bug
Comment 9 BogdanB 2021-02-12 10:15:35 UTC
*** Bug 140368 has been marked as a duplicate of this bug. ***
Comment 10 [REDACTED] 2021-03-07 21:53:58 UTC
*** Bug 140860 has been marked as a duplicate of this bug. ***
Comment 11 Hagar Delest 2021-03-16 20:19:35 UTC
*** Bug 141024 has been marked as a duplicate of this bug. ***
Comment 12 Giovanni 2021-03-17 08:38:36 UTC
The bug is in still present in LO 7.1.1 too. Can be fixed for 7.1.2 release?
Comment 13 Giovanni 2021-04-07 17:08:41 UTC
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
Comment 14 cekilch 2021-04-07 17:48:31 UTC
Bug seems to be fixed in 7.1.2 - Writer at least is working as expected & last position of cursor is saved
Comment 15 George Deluca 2021-04-07 18:07:33 UTC
When is 7.1.2 to be released?  My install is 7.1.1 and says it is up to date.
Comment 16 BogdanB 2021-04-08 04:38:43 UTC
7.1.2 was released last week. Please install and try to rerpoduce the bug.

See here:
https://www.libreoffice.org/download/download/
Comment 17 Mike Kaganski 2021-04-08 07:55:02 UTC
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.
Comment 18 Giovanni 2021-04-08 17:12:54 UTC
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.
Comment 19 Mike Kaganski 2021-04-08 18:06:14 UTC
(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.
Comment 20 Hagar Delest 2021-04-08 19:09:29 UTC
> 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.
Comment 21 Mike Kaganski 2021-04-08 19:31:45 UTC
(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.
Comment 22 Hagar Delest 2021-04-08 20:55:32 UTC
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.
Comment 23 Mike Kaganski 2021-04-08 22:31:57 UTC Comment hidden (off-topic)
Comment 24 Giovanni 2021-04-09 08:18:37 UTC
"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.
Comment 25 Giovanni 2021-04-09 08:22:14 UTC
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.
Comment 26 Mike Kaganski 2021-04-09 08:32:03 UTC
(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.
Comment 27 Giovanni 2021-04-09 11:31:21 UTC
"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.
Comment 28 Michael Warner 2021-04-09 15:42:23 UTC
(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.
Comment 29 Mike Kaganski 2021-04-09 15:53:36 UTC
(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.
Comment 30 Michael Warner 2021-04-09 22:41:41 UTC
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.
Comment 31 m_a_riosv 2021-06-11 14:34:21 UTC
*** Bug 142768 has been marked as a duplicate of this bug. ***
Comment 32 cekilch 2022-02-02 20:48:47 UTC
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.
Comment 33 Giovanni 2022-02-06 20:08:40 UTC
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.
Comment 34 Buovjaga 2022-02-07 12:10:49 UTC
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.
Comment 35 cekilch 2022-02-10 12:24:33 UTC
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.
Comment 36 Dean North 2022-04-30 15:22:29 UTC Comment hidden (me-too)
Comment 37 Justin Chu 2022-05-07 14:11:13 UTC Comment hidden (me-too)
Comment 38 hitman72ita 2022-08-30 07:40:05 UTC Comment hidden (me-too)
Comment 39 Giovanni 2022-09-05 14:33:12 UTC
It's present again in the branch 7.3. In the version 7.3.5.2
Comment 40 Buovjaga 2022-09-05 15:48:23 UTC
Before you change the version field again, read its description: "Version: (earliest affected)"
Comment 41 Giovanni 2022-09-06 21:45:14 UTC Comment hidden (no-value)
Comment 42 Hagar Delest 2022-11-18 07:19:52 UTC Comment hidden (obsolete)
Comment 43 Peter 2023-02-04 04:05:55 UTC Comment hidden (me-too)
Comment 44 Giovanni 2023-02-04 12:24:40 UTC Comment hidden (noise)
Comment 45 Buovjaga 2023-02-04 13:08:24 UTC Comment hidden (obsolete)
Comment 46 Aron Budea 2023-02-05 09:03:47 UTC
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.
Comment 47 Aron Budea 2023-02-05 09:04:36 UTC
*** Bug 142768 has been marked as a duplicate of this bug. ***
Comment 48 Aron Budea 2023-02-05 09:04:47 UTC
*** Bug 141024 has been marked as a duplicate of this bug. ***
Comment 49 Aron Budea 2023-02-05 09:05:01 UTC
*** Bug 140860 has been marked as a duplicate of this bug. ***
Comment 50 Aron Budea 2023-02-05 09:05:07 UTC
*** Bug 140368 has been marked as a duplicate of this bug. ***
Comment 51 Aron Budea 2023-02-05 09:05:56 UTC
*** Bug 153263 has been marked as a duplicate of this bug. ***
Comment 52 Aron Budea 2023-02-05 09:06:17 UTC
*** Bug 153113 has been marked as a duplicate of this bug. ***
Comment 53 Aron Budea 2023-02-05 09:06:45 UTC
*** Bug 150114 has been marked as a duplicate of this bug. ***
Comment 54 Aron Budea 2023-02-05 09:07:23 UTC
*** Bug 151427 has been marked as a duplicate of this bug. ***
Comment 55 Aron Budea 2023-02-05 09:07:36 UTC
*** Bug 152097 has been marked as a duplicate of this bug. ***
Comment 56 Aron Budea 2023-02-05 09:08:28 UTC
*** Bug 150787 has been marked as a duplicate of this bug. ***
Comment 57 Aron Budea 2023-02-05 09:11:11 UTC
*** Bug 152328 has been marked as a duplicate of this bug. ***
Comment 58 Aron Budea 2023-02-05 09:20:18 UTC
*** Bug 148785 has been marked as a duplicate of this bug. ***
Comment 59 Aron Budea 2023-02-05 09:20:54 UTC
*** Bug 148368 has been marked as a duplicate of this bug. ***
Comment 60 MR Zenwiz 2023-02-06 01:40:30 UTC
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.
Comment 61 Aron Budea 2023-02-06 06:37:09 UTC
(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.
Comment 62 elias.baalholm 2023-04-15 14:50:13 UTC
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.
Comment 63 kan 2023-04-17 09:00:20 UTC
Shift+F5 is a saviour for now. Thanks.
Comment 64 Justin L 2023-06-12 12:13:13 UTC
*** Bug 155781 has been marked as a duplicate of this bug. ***
Comment 65 V Stuart Foote 2023-06-13 21:48:42 UTC
*** Bug 155824 has been marked as a duplicate of this bug. ***
Comment 66 Mibu 2023-07-21 08:57:05 UTC
Unfortunately the bug is still present in the latest version of LO Fresh 7.5.5.2.
Comment 67 Mibu 2023-08-21 13:43:21 UTC
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?
Comment 68 Mibu 2023-09-16 12:58:14 UTC
No change: the bug persists also in the latest version of LibreOffice Fresh 7.6.1.2.
Comment 69 kan 2024-02-22 02:12:11 UTC
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