Bug Hunting Session
Bug 30763 - Missing input caret (cursor) after saving and re-opening large documents
Summary: Missing input caret (cursor) after saving and re-opening large documents
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86 (IA32) Windows (All)
: medium normal
Assignee: Cédric Bosdonnat
URL:
Whiteboard: target:3.7.0
Keywords: regression
Depends on:
Blocks:
 
Reported: 2010-10-11 00:07 UTC by luctur
Modified: 2013-03-31 08:30 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description luctur 2010-10-11 00:07:27 UTC
Here is my system:

Windows Vista Home Edition SP3
CPU AMD 64 X2 5000+
Graphic Card: Nvidia 9400GT
LibO vers: LibreOffice 3.3.0 OOO330m7 (Build:9526
Extensions installed: Italian linguistic tools  (spell checkers, thes, ...)

How to reproduce the bug/feature:

a) open a large Writer document (more than 150+ pages or 500.000 characters);

b) do same text changes in the middle of the document, save and close the documents;

c) open your document again;

What it is expected (OOo 3.2.x do so):

- the document is opened and the last page where the caret was before saving is displayed. The input caret is flashing where it was positioned when the document was saved.

What it's the current behavior:

- last page where the caret was is displayed but the input caret is missing and its last position lost. The user must click into the document to start typing.
Comment 1 Noel Power 2010-10-26 04:55:02 UTC
confirmed ( sortof ) actually for me ( using beta2 ) the document is always opened at the first page :-/ Anyway, doesn't work as it did in 3.2. Cedric can you have a look
Comment 2 Rainer Bielefeld Retired 2010-12-01 21:42:08 UTC
My results with "LibreOffice 3.3.0Beta3 - WIN XP DE [OOO330m12 (build 3.2.99.3)]" and a 160 pages complex document, where I inserted 3 lines in the middle of the document and the caret was at the end of second new line:
A) When reopening the document, view is on top of page 1 instead of latest 
   modification (bug or feature? I expected to see latest modification)
   No caret visible
B) When I press key "cursor down", caret appears somewhere in the document at a 
   selection button, no idea why that area is in the focus

I see an effect that might be related. 
1. opening new WRITER document from start center or from existing 
   Writer document using 'File -> New -> Text document', I always see 
   the caret at the start position as expected
2. opening new WRITER document from or from existing Spreadsheet document
   using 'File -> New -> Text document', I never see 
   the caret, I have to click into the document before I can start to type.
   That's unexpected.
Comment 3 Roman Eisele 2012-05-07 09:30:29 UTC
This is (at least at the surface) a Writer issue, therefore changed the
'Component' field accordingly.

Set 'Version' field according to comment #2 (no version given in original description).

Added 'regression' keyword according to original description which tells us that OOo 3.2 did not have this problem.
Comment 4 Roman Eisele 2012-05-07 09:33:05 UTC
Oh, even 3.3b2 (see comment #1)! Sorry for not seeing this at the first glance.
Comment 5 Rainer Bielefeld Retired 2012-06-29 01:23:02 UTC
Related to or same as "Bug 33568 - FILEOPEN - document not loading at last cursor position"?
Comment 6 Caolán McNamara 2012-07-05 15:38:23 UTC
The position in the document where the author/last editor was when it was saved is indeed stored into the .odt file itself, rather than into any setting in e.g. the local recently-used list.

That position is only restored if the current editor matches the author/last editor of the document, so that the person you send it to doesn't open the document at the position you were when you saved it. And an unset author/editor name doesn't count in order to avoid that everyone that didn't set their username isn't considered to be the same person.

So... that means that one needs to know both the author/last editor of a document *and* the current tools->options->user data to see if they match to determine if there's a bug in the current implementation. Testing myself locally, once I have a username set and change a huge document and reload it, then I get restored to the correct place. So, I reckon there isn't a bug here with the current implementation of that.

Its questionable if the current implementation is a good idea. e.g. other formats where we can't ram in the additional metadata. The fact the metadata is basically pixel based rather than e.g. paragraph + character index. What happens if John Smith receives a document from a different John Smith :-)
Comment 7 Caolán McNamara 2012-07-05 16:00:56 UTC
The specific problem reported here was the missing input caret rather than restoration to page 1 line 1. The measurement positioning scheme is fairly fragile. That scenario might be reproducible by anyone, with a username set, changing a document, then manually editing the settings.xml of that document and changing the ViewTop to some random number to give that missing input caret effect.


So..., maybe reproduce that way, make that work at least to give *some* caret position, and have a look at changing the positioning scheme to node+offset_within_that_node, and perhaps replicate the last-edited-position into the recently-used data.
Comment 8 Not Assigned 2012-07-09 11:57:53 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=526f80404c87a41fe46cf5694b32b469875e5c6d

Related: fdo#30763 fill in default user realname under GNOME3
Comment 9 Not Assigned 2012-07-09 11:58:17 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=5a44320a4d8c7893f596ba2ad1ef2db33fdc8b5c

Related: fdo#30763 always fill in default name under GNOME
Comment 10 Rainer Bielefeld Retired 2012-07-29 05:35:05 UTC
@Cáolan:
Is it planned to backport the fix to 3.6 and may be even 3.5 or can we close this one?
Comment 11 Jan Holesovsky 2013-03-31 08:30:13 UTC
Marking as fixed - this is in 4.0, not worth backporting to 3.6 any more.