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.
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
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.
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.
Oh, even 3.3b2 (see comment #1)! Sorry for not seeing this at the first glance.
Related to or same as "Bug 33568 - FILEOPEN - document not loading at last cursor position"?
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 :-)
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.
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
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
@Cáolan: Is it planned to backport the fix to 3.6 and may be even 3.5 or can we close this one?
Marking as fixed - this is in 4.0, not worth backporting to 3.6 any more.