When you have a multiple page document, and you move the display away from the cursor location to a different page, when it triggers an auto-save, it moves back the display to the page where the cursor was. The correct behavior would be to auto-save and let the display in the exact same position. To replicate the supposedly problem you just have to: - Make sure auto-save is enabled - Crete a document with 3 or more pages - Leave the cursor in the first page - Move the scrollbar to page 3 - Wait for the auto-save to kick-in After the save, it will move back to page 1, when you were actually reading page 3.
(In reply to Antonio Martins from comment #0) > The correct behavior would be to auto-save and let the display in the exact > same position. That is a matter of personal preference, the current behavior is equally correct in that the view shifts on save/autosave to current edit cursor position. However this issue is already open as bug 41063. *** This bug has been marked as a duplicate of bug 41063 ***
A user in bug 41063 noted that the older report was about being inside a table, while this newer problem happened after 4.4.7 and does not require being inside a table. I tested it and 4.4 does not show the problem, while 5.0.2 shows it. Thus I am setting this to NEW. I tested on Win 7 Versio: 5.0.2.2 (x64) Käännöksen ID: 37b43f919e4de5eeaca9b9755ed688758a8251fe Maa-asetus: fi-FI (fi_FI)
comments on bug 41603 -- nothing to do with table v. paragraphs always has been there in that there is not method of tracking review position of the canvas--and all positioning of updates to the canvas are linked to the edit cursor position. otherwise add dupes bug 78644 bug 92864 bug 93265 bug 93440 bug 93574 bug 94463 bug 97730 bug 97780
(In reply to V Stuart Foote from comment #3) Whoops make those dupes bug 78644 bug 92365 bug 92864 bug 93440 bug 93574 bug 94663 bug 97730 bug 97780 need better glasses again...
*** Bug 93574 has been marked as a duplicate of this bug. ***
*** Bug 78644 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #3) > comments on bug 41603 -- nothing to do with table v. paragraphs > always has been there in that there is not method of tracking review > position of the canvas--and all positioning of updates to the canvas are > linked to the edit cursor position. This is not true. The view does not jump with paragraphs in my tests with 3.5, 4.3 and 4.4.
This seems to have begun at the below commit. Adding Cc: to Bjoern Michaelsen; Could you possibly take a look at this one? Thanks ceea390d4b1631bc64f6fb1064ff685bebbdfa48 is the first bad commit commit ceea390d4b1631bc64f6fb1064ff685bebbdfa48 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed May 20 06:21:31 2015 -0500 source 07c7c88bc2d9d860ea92ab562ea0431ec1949b29 author Bjoern Michaelsen <bjoern.michaelsen@canonical.com> 2015-01-23 21:58:39 (GMT) committer Bjoern Michaelsen <bjoern.michaelsen@canonical.com> 2015-01-23 22:15:15 (GMT) commit 07c7c88bc2d9d860ea92ab562ea0431ec1949b29 (patch) tree d9cf50a4af0b3b1909bfa9c8d1c99adfbbb37f69 parent 0717643f4b061b8fd6bd59dcbdbbaf8c98c4a4dd (diff) do not use manual iteration
I can reproduce this issue on version 5.1.3.2 (Arch Linux build 1). How anyone could previously argue that this might not be a bug is absolutely incredible to me. It is a very annoying bug. I fail to see how saving (regardless whether “really saving” via Ctrl+S or auto-saving recovery information) should make the view jump. Surely restoring the view position is what should happen when a file is opened, not when it’s saved. I see a certain logic in the fact that the view is currently restored to the cursor position after opening, even if the view was shifted away from that cursor position at the time of saving. But if the file remains open after shifting the view, the natural expectation is that the view should only jump back if something happens at the cursor position: e.g. arrow keys are pressed to move the cursor, text is entered, or a previously selected word is formatted (to, say, bold) via the appropriate keyboard shortcut (Ctrl+B) or by clicking a button in a toolbar. What makes this particularly annoying is that auto-save should trigger the jump. I may want to review parts of a document deliberately before saving *and* keep the cursor where it is, using the scrollbar for the review. If I am constantly moved back to the cursor, that becomes impossible.
Jan Holesovsky committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d67042dc2f0672d1aca4784e61eb2a5d0e91e08 tdf#95797: Don't jump to the cursor position after auto-save. It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Jan Holesovsky committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=4fabfb654bc65a564da1162f10f441efce167706&h=libreoffice-5-2 tdf#95797: Don't jump to the cursor position after auto-save. It will be available in 5.2.0.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
raal: Big thanks for the bisect, fixed it now :-)
Thank you for fixing this! I’ll tag this comment as “no-value” myself, but still wanted to say it. :-)
*** Bug 100625 has been marked as a duplicate of this bug. ***
*** Bug 100667 has been marked as a duplicate of this bug. ***
*** Bug 101928 has been marked as a duplicate of this bug. ***
*** Bug 106769 has been marked as a duplicate of this bug. ***
*** Bug 109089 has been marked as a duplicate of this bug. ***
This behaviour is still occurring in 5.4.1.2 which I am using, and is very annoying when reviewing a very long document. The only workaround is to click on pages as I scroll down so the display does not jump back too far on auto save.
Dear Ben, This bug has been in RESOLVED FIXED status for more than 6 months. If the issue is still reproducible with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/, please report a new issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, if needed, the steps and documents to reproduce it. Thanks for your understanding and collaboration. Closing as RESOLVED FIXED