Since 4.3.0.4 Shift+F5 = "Restore Editing View" (means: go to the line last edited) doesn't work anymore.
Confirmed (on Windows 7 64-bit) with: Version: 4.3.0.4 Build ID: 62ad5818884a2fc2e5780dd45466868d41009ec0 Version: 4.3.1.1 Build ID: c4b15cd4d00dec6b266fa830b4ba73e31ae6ce73 Version: 4.4.0.0.alpha0+ Build ID: eacd4c044f2bdec41b02e3832772c65327e5be57 TinderBox: Win-x86@39, Branch:master, Time: 2014-08-06_08:10:42 See also: Bug 80960 - EDITING Opening file doesn't place the cursor on the last position of editing.
Confirmed on Debian (32-bit): Version: 4.3.1.2 Build ID: 958349dc3b25111dbca392fbc281a05559ef6848 Version: 4.3.2.2 Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
*** Bug 84821 has been marked as a duplicate of this bug. ***
Not reproduced on Linux (Ubuntu, 64 bit) and OSX (10.10, 64 bit) with LO 4.3.5.2, 4.4.0.2 and 4.5 master So, just as with bug 80960, there is some confusion as to the circumstances which would cause this. Note that while the initial position on load (as in bug 80960) is affected by whether you have set your name in the global configuration, when I try it, Shift+F5 goes to the cursor position saved in the file regardless of whether a name is set in global configuration.
Created attachment 112456 [details] Sample file with last cursor position set at a known position (the "X") Shift-F5 should place the cursor after the "X" on the middle line
With attachment 112456 [details], cursor is not in correct position on open. Shift+F5 does nothing. Same result from scratch. Linux Mint 17.1 32-bit, LibO 4.2.7 and 4.3.5 Win 7 Pro 64-bit, LibO Version: 4.3.6.1 Build ID: 9629686a67dd1f357477c13325e45a66f3452bb9 Version: 4.5.0.0.alpha0+ Build ID: 5f6bdce0c0ac687f418821ce328f2987bf340cda TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-01-17_01:06:46
Shift+F5 works ok with 64-bit Ubuntu. Ubuntu 14.10 64-bit Version: 4.5.0.0.alpha0+ Build ID: 0ffa3abc7d6c0437ece30cfb1430d28ffcc9f5c1 TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2015-01-15_22:47:16 Version: 4.3.3.2 Build ID: 430m0(Build:2)
On Windows 7 sp1, 64-bit en-US with these test documents https://bugs.documentfoundation.org/attachment.cgi?id=112456 https://bugs.documentfoundation.org/attachment.cgi?id=113167 Confirm Shift+F5 is not functioning with Version: 4.4.2.2 Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6 Locale: en_US but it does work correctly same system with Version: 4.5.0.0.alpha0+ Build ID: 3c6fd5a59b08cec8705a31d17a60204acf6b7173 TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2015-03-29_02:04:01 Locale: en_US Note the same behavior, i.e. 4.4.2.2 broken, 4.5.0.0alpha0+ works, with these 32-bit builds for issue of opening to last edited position when user data details (first/last/initials) are filled in, bug 80960 Have to bisect a bit but suspect Kendy's commit for bug 80960 http://cgit.freedesktop.org/libreoffice/core/commit/?id=c99e634e06aa97d9230d9200206e9c2e8e373ed0 did some good here. Also, for 64-bit Windows builds on same system Shift+F5 function is mostly correct--except for issues of bug 51217 bug 62398, where the cursor placement can be off by a dozen characters. Version: 4.5.0.0.alpha0+ (x64) Build ID: 48916c9b8c1363a37bf511626326ee6dc150975c TinderBox: Win-x86_64@42, Branch:master, Time: 2015-03-17_22:56:52 Locale: en_US and with (first/last/initials set) it opens vicinity of last edited position.
Yes, Shift+F5 "Restore Edit View" is "Mostly" fixed now for the 32-bit builds. It and the 64-bit builds still have some cursor placement issues. Bisect range... 2015-01-27..2015-01-31 http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=d1c9bd13ec7af93f5368dfda6d6d3c955f0b0816..4b9a9ce8a0e5e0716dad9a9ec87d16237e534dc2 "Mostly" in that the exact cursor position on moving the edit view seems to drift away from the last position edited. @Kendy, Maxim -- does the math for the convertTwipToMm100 for ViewTop and ViewLeft need to be refined to more precisely place the cursor?
The document provided as example has no author. Therefore it is a bad example for testing the cursor position at opening. If you place the cursor on the X and then save the document (using LibreOffice 4.4.3.1) when you reopen it with the same user it will show the cursor on the X. If you open the document from another user account it will jump to the same exact position by pressing Shift+F5 At least under Windows XP Pro x86 SP3 everything is now working as expected.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
On Windows 10 Pro 64-bit en-US Version: 5.1.2.2 (x64) Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) Verified <shift>+F5 working correctly to relocate as close as can be calculated prior position Believe this should have been closed, fixed as noted Comment 9