Bug 140147 - position of cursor not saved
Summary: position of cursor not saved
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.1.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 140368 140860 141024 142768 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-02-04 10:54 UTC by cekilch
Modified: 2021-06-11 14:34 UTC (History)
6 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
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.
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. ***