Download it now!
Bug 82300 - Shift+F5 = Restore Editing View doesn't work anymore
Summary: Shift+F5 = Restore Editing View doesn't work anymore
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.3.0.4 release
Hardware: All Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-07 14:46 UTC by Sebastian von Kracht
Modified: 2016-04-16 16:45 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Sample file with last cursor position set at a known position (the "X") (8.49 KB, application/vnd.oasis.opendocument.text)
2015-01-19 11:21 UTC, Matthew Francis
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Sebastian von Kracht 2014-08-07 14:46:28 UTC
Since 4.3.0.4 Shift+F5 = "Restore Editing View" (means: go to the line last edited) doesn't work anymore.
Comment 1 manj_k 2014-08-07 15:35:22 UTC
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.
Comment 2 Geoff 2014-10-11 08:03:33 UTC
Confirmed on Debian (32-bit):

Version: 4.3.1.2
Build ID: 958349dc3b25111dbca392fbc281a05559ef6848

Version: 4.3.2.2
Build ID: edfb5295ba211bd31ad47d0bad0118690f76407d
Comment 3 tommy27 2014-10-19 07:20:34 UTC
*** Bug 84821 has been marked as a duplicate of this bug. ***
Comment 4 Matthew Francis 2015-01-19 11:19:39 UTC
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.
Comment 5 Matthew Francis 2015-01-19 11:21:31 UTC
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
Comment 6 Buovjaga 2015-01-20 07:34:49 UTC
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
Comment 7 Buovjaga 2015-01-20 07:40:19 UTC
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)
Comment 8 V Stuart Foote 2015-04-01 00:03:07 UTC
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.
Comment 9 V Stuart Foote 2015-04-01 02:18:59 UTC
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?
Comment 10 Pedro 2015-04-16 14:43:30 UTC
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.
Comment 11 tommy27 2016-04-16 07:26:10 UTC Comment hidden (obsolete)
Comment 12 V Stuart Foote 2016-04-16 16:45:29 UTC
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