Bug Hunting Session
Bug 41063 - Saving/Autosaving (Save/Autosave) while in table causes view to jump to cursor position
Summary: Saving/Autosaving (Save/Autosave) while in table causes view to jump to curso...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: high major
Assignee: Mike Kaganski
URL:
Whiteboard: target:6.2.0
Keywords: needsDevEval, topicUI
: 92365 92864 93440 94663 96005 97730 97780 100059 105506 (view as bug list)
Depends on:
Blocks: Writer-Tables Writer-View-Jumps Save
  Show dependency treegraph
 
Reported: 2011-09-20 17:13 UTC by David Tombs
Modified: 2018-07-27 22:29 UTC (History)
38 users (show)

See Also:
Crash report or crash signature:


Attachments
sample document demonstrating the issue (8.53 KB, application/vnd.oasis.opendocument.text)
2011-09-20 17:13 UTC, David Tombs
Details
debugging code showing one factor (progressbar) that triggers the screen refresh (6.98 KB, patch)
2016-12-27 14:53 UTC, Justin L
Details
Example file with a table that forces a jump and with a table that doesn't force a jump (11.44 KB, application/vnd.oasis.opendocument.text)
2017-03-06 22:56 UTC, Thomas Lendo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Tombs 2011-09-20 17:13:47 UTC
Created attachment 51440 [details]
sample document demonstrating the issue

In the attached document (a simple two-page document with a table), saving will
cause the screen to scroll jump to the cursor position.

Steps to reproduce:
1) Type some information in the table.
2) Mouse-wheel scroll down to the second page.
3) Click the save button.
4) View jumps back to the table.

Same thing happens with autosave, which I tested by setting autosave down to 1
minute.

Bug report copied from <http://openoffice.org/bugzilla/show_bug.cgi?id=111894>.
Comment 1 Björn Michaelsen 2011-12-23 12:36:33 UTC Comment hidden (obsolete)
Comment 2 David Tombs 2011-12-27 16:31:27 UTC
I can reproduce with 3.5.0 beta 2.
Comment 3 David Tombs 2011-12-27 16:32:18 UTC
By the way, this bug is registered in Ubuntu at: <https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/248870>
Comment 4 A (Andy) 2013-05-01 07:29:30 UTC
reproducible with LO 4.0.2.2 (Win7 Home, 64bit)

But I don't think this is a bug, because after saving the file, it should jump back to the page where the cursor is and it does it as expected, because with the mouse scrolling I am not changing the position of the cursor.  Therefore, this is correct for me and the normal behavior.
Can anybody else confirm this?
Comment 5 David Tombs 2013-05-02 00:58:46 UTC
Well, it breaks my expectations along with a few other users of Ubuntu at least. Why would you want the cursor to jump upon save?
Comment 6 QA Administrators 2015-03-04 02:24:12 UTC Comment hidden (obsolete)
Comment 7 Jean-Baptiste Faure 2015-03-07 11:10:09 UTC
(In reply to David Tombs from comment #5)
> Well, it breaks my expectations along with a few other users of Ubuntu at
> least. Why would you want the cursor to jump upon save?

The cursor does not jump upon save, it is in the table and the view jump to the current cursor position. As you are in edit mode, it is not a stupid idea.

Closing as NotABug. Please, feel free to reopen if you disagree.

Best regards. JBF
Comment 8 David Tombs 2015-03-07 22:15:23 UTC
I do disagree. I misspoke earlier, I should have said "Why would you want the _view_ to jump upon save?"

This is especially unexpected when autosave kicks in. You could be reading a totally different part of the document and LibreOffice jumps you back to your cursor through no action of your own!

This bug still exists on 4.2.7.2, I will test on 4.4+ when I get a chance.
Comment 9 Jean-Baptiste Faure 2015-03-07 22:26:32 UTC
You can't set your own bug report to new. It must be independently confirmed.
Thank you for your understanding.
Comment 10 Jean-Baptiste Faure 2015-03-07 22:30:58 UTC
Requesting UX to get involved.
I maintain that I think it is not a bug.

Best regards. JBF
Comment 11 Buovjaga 2015-03-18 15:49:28 UTC
For what it's worth, MS Word does not jump to the table after saving.

Win 8 32-bit
MSO 2013
Comment 12 Matthew Francis 2015-03-22 15:11:55 UTC
I concur that this should be seen as a bug.

If I'm scrolling through a large document to find some particular position, I absolutely do not want the view to change randomly to wherever the cursor was left just because an autosave happens to occur at that moment.

Autosave in particular should be as transparent as possible, though I don't particularly see why a manual save should move the view either. View position and cursor position are separate for a reason, and neither should be changed by actions that aren't individually relevant to one or the other.

Setting -> NEW
Comment 13 Alex Thurgood 2015-06-28 08:26:38 UTC
*** Bug 92365 has been marked as a duplicate of this bug. ***
Comment 14 Jean-Baptiste Faure 2015-07-24 20:12:39 UTC
*** Bug 92864 has been marked as a duplicate of this bug. ***
Comment 15 John 2015-08-12 18:54:27 UTC
This bug also occurs (as the Ubuntu report showed) when the cursor is not in a table. Simply have the cursor in a paragraph, scroll a bit so that the cursor is off the screen, and save the document. The view will jump to show the paragraph that contains the cursor and the cursor in it.

Mac version 5.0.0.5

Just want to add my support for this being a bug. I often do some editing, scroll a bit, and then hit save, often without thinking about it. Nothing should change in what I'm viewing when I do that.
Comment 16 Paul Morris 2015-08-13 18:54:24 UTC
+1 for everything in comment 15

I'm also on Mac version 5.0.0.5, and I did not notice this happening before upgrading to LibreOffice 5.0
Comment 17 Yousuf Philips (jay) (retired) 2015-08-16 19:34:19 UTC
Yes saving shouldnt cause the view to jump to wherever the cursor is.
Comment 18 V Stuart Foote 2015-08-17 01:25:21 UTC
*** Bug 93440 has been marked as a duplicate of this bug. ***
Comment 19 Chris Halls 2015-09-21 11:36:06 UTC
Also reported in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799428
Comment 20 Aethralis 2015-09-23 13:37:50 UTC
I previously did not have this issue, it started with LO 5.0.1.2. Using Ubuntu 14.04.
Comment 21 KDM 2015-10-03 20:14:10 UTC
Have this issue using LO 5.0.2.2 in Windows 10 64bit sys. Agree that this is a bug. I know of no situation where I would want the program to change screen position on 'save.' Jumping to the last cursor position on 'open' or re-loading a document for editing makes sense, but doing so on 'save' does not.  Thanks!
Comment 22 Jeppe Bundsgaard 2015-10-30 08:02:31 UTC
I did not have this problem before version 5.0. This is an extremely annoying bug. 
Using:
Version: 5.0.2.2
Build ID: 00m0(Build:2)
Lokalisering: da-DK (da_DK.UTF-8)
Comment 23 KDM 2015-11-09 15:42:36 UTC
Updated to Version: 5.0.3.2 today, the problem persists. VERY annoying.
Comment 24 V Stuart Foote 2015-11-14 13:40:49 UTC
*** Bug 95797 has been marked as a duplicate of this bug. ***
Comment 25 KDM 2015-11-17 20:57:01 UTC
Reading the comments on duplicates of this BUG, it seems that some feel this is correct behavior, or a matter of personal preference. I suppose you could say that's true. Just as, if you prefer to return to the behavior of antique emacs-like editors where your cursor position IS your view position, that would also be a personal preference. But it seems to me that the whole reason most people like having scroll bars and windows in a word processor is precisely so they CAN navigate away from their current cursor position to see another part of the document and not have the program arbitrarily and unexpectedly change that view for reasons of it's own. It may be a personal preference, but since I can think of no other word processing program (or even modern text editor) that does this, I believe it is a relatively universal preference and expectation.
Comment 26 Robinson Tryon (qubit) 2015-12-13 11:24:26 UTC Comment hidden (obsolete)
Comment 27 Aibara 2016-02-01 05:26:45 UTC
This is an especially huge pain when editing documents: I'll have just edited a sentence, then be reading on and scrolling down and reading on for the next problem when the document will autosave and I'll lose my place. It'd be wonderful if this were fixed.
Comment 28 Buovjaga 2016-02-12 16:58:58 UTC
*** Bug 97730 has been marked as a duplicate of this bug. ***
Comment 29 Adolfo Jayme 2016-02-17 07:33:16 UTC
*** Bug 97780 has been marked as a duplicate of this bug. ***
Comment 30 Jerry Van Brimmer 2016-03-01 17:48:24 UTC
I agree that this should be considered a bug. The view should not change just because an autosave occurs, it's very annoying. 

I have confirmed that this DOES NOT happen in version 4.4.7.2, but it did show up in 5.0.0.1. So, it was reintroduced in the 5.x series.

I just tested version 5.1.1.1 this morning, and this behavior is still there. So, for me, until this is fixed I'm sticking to 4.4.7.2.
Comment 31 Sccrow 2016-03-03 15:27:26 UTC
It also happen  when you do a save.
Comment 32 Zarko Zivanov 2016-03-29 21:53:51 UTC
I also consider this a bug, and I agree that (auto)saving shouldn't change current view to current cursor position (if I want that, I can always press one of the cursor keys). This disrupts working with documents when one just needs to check other part of the document while working on the current one.

I can confirm that this happens in LO 5.1.1.2 (Ubuntu 64bit, LO from LO PPA).
Comment 33 Jean-Baptiste Faure 2016-04-30 06:01:01 UTC
Nobody gave a version number in which it worked differently, so it is not a regression. Keyword regression removed.

Best regards. JBF
Comment 34 sdc.blanco 2016-04-30 06:38:42 UTC
about regression, see comment 30
Comment 35 Buovjaga 2016-04-30 06:52:31 UTC
(In reply to sdc.blanco from comment #34)
> about regression, see comment 30

Well, the bug existed already before 3.5.

Can you confirm the bug is not in 4.4.7?
Comment 36 James A. Schulz 2016-04-30 07:09:48 UTC
I have never seen this behavior in any previous (previous to v. 5.x) Windows version.  It is definitely a regression, and most annoying one.

The idea that this is not a bug makes no sense to me.  I reread while I am writing.  I go back a couple pages to see how I said something and sometimes I notice a typo (in that passate) and I correct it, then I return to end of my text (CTRL-END) and continue writing where I left off, suddenly auto-save kicks in and I find myself back at the typo I had corrected two minutes previously. I cannot imagine anybody would be happy with that behavior.
Comment 37 sdc.blanco 2016-04-30 08:44:56 UTC
Regression report in relation 4.4.7.2
(+ important additional precision in bug report)

For Version: 4.4.7.2
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Windows 7

Test #1

1. Cursor is placed on p. 1, but not in table 
2. Mouse Scroll to page 2 
3. with both autosave or manual save:   NO jumpback (i.e., screen remains on p. 2)

Test #2  (original bug report)

1. Cursor placed on p. 1, but IN  table
2. Mouse Scroll to page 2 -
3. with both autosave or manual save:  JUMPBACK to cursor on p. 1


For Version: 5.1.2.2
Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
Locale: da-DK (da_DK)

1.  Does not matter whether cursor is in table or in text on p.1,  

2.  Mouse scroll to page 2

3. With both autosave and save, jumps back to the cursor on page 1 (regardless of whether cursor was in table or text)

Conclusion:

1.  Original bug report was in relation to cursor in table.  This problem appears in both 4.4.7.2 and 5.1.2.2 (Windows)

2.  So I agree that this behavior (with the cursor in the table) is not a regression.

3.  But there is a change/difference between 4.4.7.2 and 5.1.2.2 if the cursor is NOT in a table.  For 4.4.7.2, the save/autosave will leave the screen view as it was.  With 5.1.2.2, the save/autosave will return the screen view of where the cursor was found.

4.  I want to raise the hypothesis that some of the reports, after the original bug report, may not have appreciated that the problem was reported in relation to a cursor in a table!  

    a.  They may have been referring to the situation where the cursor was NOT a table  (i.e., a different situation). (this is noted explicitly in comment 15)
    b.  In these cases, it seems that the screen view does change (at least with 5.1.2.2), and many of the reports here seem to indicate that this behavior started with 5.x series.  (see comment 15 through comment 22 )
    c.  Some think it should do that (comment 4)  others do not (comment 12 and comment 17 and others)

5.  I will not make any changes here, but will leave the matter for QA folk to make appropriate changes in the bugtracker (i.e., if a new bug report should be created for the new situation).

6.  Maybe the summary title of this bug should be changed to include the words "cursor in the table" to make the matter clear.

7.  Finally, I will remove this bug from the Autosave/Autorecovery meta bug, because it not an issue with Autosave/Autorecovery
Comment 38 sdc.blanco 2016-04-30 09:22:50 UTC
P.S. I believe the problem with changing focus (after a mouse scroll) from another page than where the cursor is found is reported in bug 78644, bug 94663, and bug 93574 (but there are small variations between them. I could not find a consistent story across them.)
Comment 39 KDM 2016-04-30 17:45:35 UTC
(In reply to James A. Schulz from comment #36)
> I have never seen this behavior in any previous (previous to v. 5.x) Windows
> version.  It is definitely a regression, and most annoying one.
> 
> The idea that this is not a bug makes no sense to me.  I reread while I am
> writing.  I go back a couple pages to see how I said something and sometimes
> I notice a typo (in that passate) and I correct it, then I return to end of
> my text (CTRL-END) and continue writing where I left off, suddenly auto-save
> kicks in and I find myself back at the typo I had corrected two minutes
> previously. I cannot imagine anybody would be happy with that behavior.

This is confusing to me... If you "return to end" and "continue writing" have you not moved your cursor to the end? In which case, the jump back to where you corrected the typo appears to be a totally different problem.
Comment 40 KDM 2016-04-30 17:54:27 UTC
(In reply to sdc.blanco from comment #37)
> Regression report in relation 4.4.7.2
> (+ important additional precision in bug report)
> 
> For Version: 4.4.7.2
> Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
> Windows 7
> 
> Test #1
> 
> 1. Cursor is placed on p. 1, but not in table 
> 2. Mouse Scroll to page 2 
> 3. with both autosave or manual save:   NO jumpback (i.e., screen remains on
> p. 2)
> 
> Test #2  (original bug report)
> 
> 1. Cursor placed on p. 1, but IN  table
> 2. Mouse Scroll to page 2 -
> 3. with both autosave or manual save:  JUMPBACK to cursor on p. 1
> 
> 
> For Version: 5.1.2.2
> Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f
> CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; 
> Locale: da-DK (da_DK)
> 
> 1.  Does not matter whether cursor is in table or in text on p.1,  
> 
> 2.  Mouse scroll to page 2
> 
> 3. With both autosave and save, jumps back to the cursor on page 1
> (regardless of whether cursor was in table or text)
> 
> Conclusion:
> 
> 1.  Original bug report was in relation to cursor in table.  This problem
> appears in both 4.4.7.2 and 5.1.2.2 (Windows)
> 
> 2.  So I agree that this behavior (with the cursor in the table) is not a
> regression.
> 
> 3.  But there is a change/difference between 4.4.7.2 and 5.1.2.2 if the
> cursor is NOT in a table.  For 4.4.7.2, the save/autosave will leave the
> screen view as it was.  With 5.1.2.2, the save/autosave will return the
> screen view of where the cursor was found.
> 
> 4.  I want to raise the hypothesis that some of the reports, after the
> original bug report, may not have appreciated that the problem was reported
> in relation to a cursor in a table!  
> 
>     a.  They may have been referring to the situation where the cursor was
> NOT a table  (i.e., a different situation). (this is noted explicitly in
> comment 15)
>     b.  In these cases, it seems that the screen view does change (at least
> with 5.1.2.2), and many of the reports here seem to indicate that this
> behavior started with 5.x series.  (see comment 15 through comment 22 )
>     c.  Some think it should do that (comment 4)  others do not (comment 12
> and comment 17 and others)
> 
> 5.  I will not make any changes here, but will leave the matter for QA folk
> to make appropriate changes in the bugtracker (i.e., if a new bug report
> should be created for the new situation).
> 
> 6.  Maybe the summary title of this bug should be changed to include the
> words "cursor in the table" to make the matter clear.
> 
> 7.  Finally, I will remove this bug from the Autosave/Autorecovery meta bug,
> because it not an issue with Autosave/Autorecovery

This sums it up well. But while it's true that the original post was specific to text in tables (maybe NOT a regression but still a problem), others have opened bug reports about the issue when it involves text outside of tables and those bug reports have always been merged into this one. Thank you for helping to further clarify the issue.
Comment 41 Buovjaga 2016-05-02 13:13:44 UTC
*** Bug 94663 has been marked as a duplicate of this bug. ***
Comment 42 sdc.blanco 2016-05-03 06:35:21 UTC
(In reply to Jean-Baptiste Faure from comment #33)
> Nobody gave a version number in which it worked differently, so it is not a
> regression. Keyword regression removed.
> 
> Best regards. JBF

Just checking. It seems like there are two different bugs here,  one, where the cursor is in a table (the original report), and one where the cursor is not. 
I believe the second case is a regression, where the latest version that worked correctly was 4.4.7.2. (see comment 37)  Shouldn't that be set up a separate bug , and marked as a regression (so that it can get a higher priority)? 

Or alternatively, maybe it is set up as a bug, see comment 38, and one of those should be marked as a regression?
Comment 43 Jean-Baptiste Faure 2016-05-06 15:24:53 UTC
(In reply to sdc.blanco from comment #42)
> (In reply to Jean-Baptiste Faure from comment #33)
> > Nobody gave a version number in which it worked differently, so it is not a
> > regression. Keyword regression removed.
> > 
> > Best regards. JBF
> 
> Just checking. It seems like there are two different bugs here,  one, where
> the cursor is in a table (the original report), and one where the cursor is
> not. 
> I believe the second case is a regression, where the latest version that
> worked correctly was 4.4.7.2. (see comment 37)  Shouldn't that be set up a
> separate bug , and marked as a regression (so that it can get a higher
> priority)? 

Yes.

Best regards. JBF
Comment 44 Buovjaga 2016-05-09 10:14:18 UTC
I undid the duplication of bug 95797. Let's keep it as the regression from 4.4.7.
Comment 45 V Stuart Foote 2016-05-09 16:09:38 UTC
(In reply to Buovjaga from comment #44)
> I undid the duplication of bug 95797. Let's keep it as the regression from
> 4.4.7.

;-) care to explain bug 78644?  Actually though there are several facets at play. But, I don't agree there are two issues to be resolved--an edit cursor in Tables is handled the same as an edit cursor in any document paragraph.

=-edit cursor and edit View-=

1. Shift+F5 (bug 80960 & bug 82300) recording the last cursor position ViewLeft and ViewTop into the settings.xml of the ODF archive.  Those set the edit View on opening of document if an entry is present for user identity. Without the user identity, the document opens at its Top.  In either case the Shfit+F5 positions view to the last edit cursor location as saved per document in its settings.xml.

2. Save/Auto-save has never written to the actual document, rather it writes to temporary copy.

3. Unless you actually save (auto or manual) and also close the document the active settings.xml is not replaced/updated and the Shift+F5 continues to point to edit cursor location as was set at opening a document

4. When you save/close and reopen the Shift+F5 edit cursor position and a new edit View will be where it had been positioned on saving.

Enhancement here would be a method to force update of the settings.xml during the edit session so that Shift+F5 can be reset during an edit session.  And see that as related to bug 92821 to establish a number of edit locations to cycle through.


=-document canvas View-=

This has room for enhancement. And is the main gripe that folks have had--it did not just start at 5.0

There is currently no mechanism providing hooks to track scrolling view of the document pane and return to that location.  Sure there are Home, End, PageDown, PageUp but those are simple repositioning of the canvas frame. The most granular measure when scrolling the canvas seems to be page units!

Enhancment here would be that Save (Ctrl+S) or Auto-Save would not reposition document canvas view back to the last edit cursor location. Nor of course to the edit View (Shift+F5) of the active settings.xml

Rather additional canvas positioning hooks are needed for use in the current edit session so that canvas view can be kept isolated from the edit cursor.
Comment 46 Sccrow 2016-05-09 19:53:17 UTC Comment hidden (me-too)
Comment 47 Buovjaga 2016-05-10 08:51:34 UTC
(In reply to V Stuart Foote from comment #45)
> ;-) care to explain bug 78644?  Actually though there are several facets at
> play. But, I don't agree there are two issues to be resolved--an edit cursor
> in Tables is handled the same as an edit cursor in any document paragraph.

Apparently not.

In 4.4.5, saving while cursor is in a table jumps the view back from wherever you had scrolled it.

In 4.4.5, saving while cursor is in a paragraph does not jump the view back.
Comment 48 Tim Chambers 2016-05-23 06:49:00 UTC Comment hidden (me-too)
Comment 49 Mihkel Tõnnov 2016-05-26 09:29:56 UTC Comment hidden (me-too)
Comment 50 Cor Nouws 2016-05-26 10:37:48 UTC
*** Bug 100059 has been marked as a duplicate of this bug. ***
Comment 51 V Stuart Foote 2016-05-26 13:14:56 UTC
*** Bug 96005 has been marked as a duplicate of this bug. ***
Comment 52 V Stuart Foote 2016-05-26 13:58:10 UTC
@Kendy, *

see my comment 45

Rather than a bug, I see this (and duplicate bug 95797) as a needed UI enhancement along with bug 92821.

Beyond http://opengrok.libreoffice.org/xref/core/sw/source/uibase/uiview/view.cxx#1238 that sets behavior on opening a document or during editing with <Shift>+F5 movement, are there any indicators of the canvas view point while the document has been scrolled away from the edit cursor? I don't believe so.

IIUC we don't explicitly manage the view point during editing, so have no control possible for return from a manual or auto save. On resuming, view opens to the last edit cursor position at time of save.

Would there be some way to enhance this and provide hooks during an edit session (beyond the current single restore view on opening) to avoid the scroll back "jump"?  And perhaps to provide for multiple <Shift>+F5 view points to cycle through as in the bug 92821 enhancement?
Comment 53 David Tombs 2016-05-27 15:02:40 UTC
I, as the original reporter, am clarifying this bug title to differentiate it from the apparent regression bug 95797.
Comment 54 David Tombs 2016-05-27 15:07:48 UTC
Note that when I originally filed this bug, I could _only_ reproduce it with the cursor in a table. The view jump did not happen otherwise.
Comment 55 evan 2016-06-26 22:11:32 UTC Comment hidden (me-too)
Comment 56 V Stuart Foote 2016-06-27 00:30:30 UTC
(In reply to evan from comment #55)
> I can confirm this behavior in 5.0.4.2.
> 
> This happens regardless of whether the cursor is in a table.
> 
> I can understand the jump to the last cursor position upon opening, but
> doing this during save/autosave is definitely not desirable for me.
> 
> For example, if my cursor is at the bottom of the document and I scroll up
> to review something I typed on a previous page, it is very annoying for
> Libreoffice to move me away from what I was reading.

That is bug 95797, now resolved fixed for 5.2.0, which was split from this issue. This issue is restricted to scroll view behavior when edit cursor is in table on Save/Auto-save.
Comment 57 Justin L 2016-12-27 14:53:28 UTC
Created attachment 129961 [details]
debugging code showing one factor (progressbar) that triggers the screen refresh

The debugging patch led to the gtkdata brick wall of Yield()
   wasOneEvent = g_main_context_iteration( nullptr, bWait && !bWasEvent );

When bHandleAllCurrentEvents is true, then one of the events that runs causes the screen repositioning.  The Save procedure's progress bar is one item that calls for a Yield(bHandleAllCurrentEvents=true).  However, there is some other unknown thing that also triggers the screen repositioning long after the save procedure has finished.

CC  Caolán McNamara - I'm drowning here.  Impossible to fix?
Comment 58 V Stuart Foote 2017-01-24 17:46:01 UTC
*** Bug 105506 has been marked as a duplicate of this bug. ***
Comment 59 Thomas Lendo 2017-03-06 22:56:57 UTC
Created attachment 131687 [details]
Example file with a table that forces a jump and with a table that doesn't force a jump

I tested the jump at autosave/save issue with an old file created with OOo 3.0.1 in 2009. No jumps occur with that file. (https://bz.apache.org/ooo/show_bug.cgi?id=99963)

I created a new file with LibO 5.3.0.3 on Ubuntu Linux 14.04 with a new 2 column table ("first table") and a bigger table that I copied from the old OOo file ("second table").

Steps to reproduce:
1. Open my attached file.
2. Change something (no matter where or what you insert or delete a letter).
3. Set the cursor into the first or second table.
4. Scroll the the bottom of the page so that the content is out of view.

Result:

If the cursor is in the second (bottom) table, saving the document will not jump the view to cursor position.

If the cursor is in the first (upper) table, saving the document will jump the view to cursor position.
Comment 60 Heiko Tietze 2017-03-07 07:09:26 UTC
(In reply to V Stuart Foote from comment #45)
> This has room for enhancement. And is the main gripe that folks have had--it
> did not just start at 5.0

I don't see the need for UX eval. This clearly describes the issue- and you also state the solution:

> Enhancment here would be that Save (Ctrl+S) or Auto-Save would not
> reposition document canvas view back to the last edit cursor location. Nor
> of course to the edit View (Shift+F5) of the active settings.xml
> 
> Rather additional canvas positioning hooks are needed for use in the current
> edit session so that canvas view can be kept isolated from the edit cursor.

Whether this is an enhancement or a bug is a different question. Following comment 59 the issue is a regression too.
Comment 61 Mike Kaganski 2017-05-24 13:31:49 UTC
(In reply to Heiko Tietze from comment #60)
> Following comment 59 the issue is a regression too.

This isn't a regression. The same behavior is with OOO330m20 (Build:9567) and OOO310m19 (Build:9420).
Comment 62 Mike Kaganski 2017-05-25 05:44:39 UTC
(In reply to Thomas Lendo from comment #59)
> I tested the jump at autosave/save issue with an old file created with OOo
> 3.0.1 in 2009. No jumps occur with that file.
> (https://bz.apache.org/ooo/show_bug.cgi?id=99963)

This isn't related to a version that created the file. It turns out that no jump to table happens when cursor is in a *list* inside a table (the last two paragraphs in second table's right cell are part of a bullet list). Creating a list in any other table and putting cursor there prevents jumping back in any document.
Comment 63 V Stuart Foote 2018-01-18 19:34:40 UTC
*** Bug 114729 has been marked as a duplicate of this bug. ***
Comment 64 V Stuart Foote 2018-01-18 19:41:27 UTC
(In reply to V Stuart Foote from comment #63)
> *** Bug 114729 has been marked as a duplicate of this bug. ***

Sorry. Dyslexia at play... ref issue is a duplicate of bug 40163 not this.
Comment 65 J22Gim 2018-07-06 09:35:27 UTC Comment hidden (me-too)
Comment 66 J22Gim 2018-07-12 02:52:45 UTC
Reproducible with Version: 6.0.1.1
Build ID: 60bfb1526849283ce2491346ed2aa51c465abfe6
CPU threads: 4; OS: Linux 4.4; UI render: default; VCL: kde4; 
Locale: en-US (en_US.UTF-8); Calc: group
Comment 67 Mike Kaganski 2018-07-26 05:11:13 UTC
The call stack that resets the view is the following:

> swlo.dll!SwViewShell::IsViewLocked() Line 461
> 	at c:\lo\core\sw\inc\viewsh.hxx(461)
> swlo.dll!SwViewShell::MakeVisible(const SwRect & rRect) Line 572
> 	at c:\lo\core\sw\source\core\view\viewsh.cxx(572)
> swlo.dll!SwCursorShell::MakeSelVisible() Line 2828
> 	at c:\lo\core\sw\source\core\crsr\crsrsh.cxx(2828)
> swlo.dll!SwFEShell::MakeSelVisible() Line 2584
> 	at c:\lo\core\sw\source\core\frmedt\feshview.cxx(2584)
> swlo.dll!SwCursorShell::UpdateCursor(unsigned short eFlags, bool bIdleEnd) Line 1844
> 	at c:\lo\core\sw\source\core\crsr\crsrsh.cxx(1844)
> swlo.dll!SwCursorShell::EndAction(const bool bIdleEnd, const bool DoSetPosX) Line 274
> 	at c:\lo\core\sw\source\core\crsr\crsrsh.cxx(274)
> swlo.dll!SwCursorShell::CheckTableBoxContent(const SwPosition * pPos) Line 868
> 	at c:\lo\core\sw\source\core\crsr\trvltbl.cxx(868)
> swlo.dll!SwCursorShell::EndAllTableBoxEdit() Line 923
> 	at c:\lo\core\sw\source\core\crsr\trvltbl.cxx(923)
> swlo.dll!SwDocShell::SaveAs(SfxMedium & rMedium) Line 506
> 	at c:\lo\core\sw\source\uibase\app\docsh.cxx(506)
> sfxlo.dll!SfxObjectShell::SaveAsOwnFormat(SfxMedium & rMedium) Line 3087
> 	at c:\lo\core\sfx2\source\doc\objstor.cxx(3087)
> sfxlo.dll!SfxObjectShell::SaveTo_Impl(SfxMedium & rMedium, const SfxItemSet * pSet) Line 1427
> 	at c:\lo\core\sfx2\source\doc\objstor.cxx(1427)
> sfxlo.dll!SfxObjectShell::PreDoSaveAs_Impl(const rtl::OUString & rFileName, const rtl::OUString & aFilterName, const SfxItemSet & rItemSet) Line 2847
> 	at c:\lo\core\sfx2\source\doc\objstor.cxx(2847)
> sfxlo.dll!SfxObjectShell::CommonSaveAs_Impl(const INetURLObject & aURL, const rtl::OUString & aFilterName, SfxItemSet & rItemSet) Line 2705
> 	at c:\lo\core\sfx2\source\doc\objstor.cxx(2705)
> sfxlo.dll!SfxObjectShell::APISaveAs_Impl(const rtl::OUString & aFileName, SfxItemSet & rItemSet) Line 307
> 	at c:\lo\core\sfx2\source\doc\objserv.cxx(307)
> sfxlo.dll!SfxBaseModel::impl_store(const rtl::OUString & sURL, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & seqArguments, bool bSaveTo) Line 2970
> 	at c:\lo\core\sfx2\source\doc\sfxbasemodel.cxx(2970)
> sfxlo.dll!SfxBaseModel::storeToRecoveryFile(const rtl::OUString & i_TargetLocation, const com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue> & i_MediaDescriptor) Line 1666
> 	at c:\lo\core\sfx2\source\doc\sfxbasemodel.cxx(1666)
> fwklo.dll!`anonymous namespace'::AutoRecovery::implts_saveOneDoc(const rtl::OUString & sBackupPath, `anonymous-namespace'::AutoRecovery::TDocumentInfo & rInfo, const com::sun::star::uno::Reference<com::sun::star::task::XStatusIndicator> & xExternalProgress) Line 3061
> 	at c:\lo\core\framework\source\services\autorecovery.cxx(3061)
> fwklo.dll!`anonymous namespace'::AutoRecovery::implts_saveDocs(bool bAllowUserIdleLoop, bool bRemoveLockFiles, const `anonymous-namespace'::DispatchParams * pParams) Line 2960
> 	at c:\lo\core\framework\source\services\autorecovery.cxx(2960)
> fwklo.dll!`anonymous namespace'::AutoRecovery::implts_timerExpired(Timer * __formal) Line 2310
> 	at c:\lo\core\framework\source\services\autorecovery.cxx(2310)
> fwklo.dll!`anonymous namespace'::AutoRecovery::LinkStubimplts_timerExpired(void * instance, Timer * data) Line 2248
> 	at c:\lo\core\framework\source\services\autorecovery.cxx(2248)
> vcllo.dll!Link<Timer *,void>::Call(Timer * data) Line 84
> 	at c:\lo\core\include\tools\link.hxx(84)
> vcllo.dll!Timer::Invoke() Line 77
> 	at c:\lo\core\vcl\source\app\timer.cxx(77)
> vcllo.dll!Scheduler::ProcessTaskScheduling() Line 448
> 	at c:\lo\core\vcl\source\app\scheduler.cxx(448)
> vcllo.dll!Scheduler::CallbackTaskScheduling() Line 271
> 	at c:\lo\core\vcl\source\app\scheduler.cxx(271)
> vcllo.dll!SalTimer::CallCallback() Line 56
> 	at c:\lo\core\vcl\inc\saltimer.hxx(56)
> vcllo.dll!WinSalTimer::ImplHandleElapsedTimer() Line 158
> 	at c:\lo\core\vcl\win\app\saltimer.cxx(158)
> vcllo.dll!WinSalTimer::ImplHandleTimerEvent(unsigned __int64 aWPARAM) Line 168
> 	at c:\lo\core\vcl\win\app\saltimer.cxx(168)
> vcllo.dll!SalComWndProc(HWND__ * __formal, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam, bool & rDef) Line 642
> 	at c:\lo\core\vcl\win\app\salinst.cxx(642)
> vcllo.dll!SalComWndProcW(HWND__ * hWnd, unsigned int nMsg, unsigned __int64 wParam, __int64 lParam) Line 670
> 	at c:\lo\core\vcl\win\app\salinst.cxx(670)
> user32.dll!UserCallWinProcCheckWow()
> user32.dll!DispatchMessageWorker()
> vcllo.dll!ImplSalDispatchMessage(const tagMSG * pMsg) Line 458
> 	at c:\lo\core\vcl\win\app\salinst.cxx(458)
> vcllo.dll!ImplSalYield(bool bWait, bool bHandleAllCurrentEvents) Line 526
> 	at c:\lo\core\vcl\win\app\salinst.cxx(526)
> vcllo.dll!WinSalInstance::DoYield(bool bWait, bool bHandleAllCurrentEvents) Line 555
> 	at c:\lo\core\vcl\win\app\salinst.cxx(555)
> vcllo.dll!ImplYield(bool i_bWait, bool i_bAllEvents) Line 470
> 	at c:\lo\core\vcl\source\app\svapp.cxx(470)
> vcllo.dll!Application::Yield() Line 536
> 	at c:\lo\core\vcl\source\app\svapp.cxx(536)
> vcllo.dll!Application::Execute() Line 450
> 	at c:\lo\core\vcl\source\app\svapp.cxx(450)
> sofficeapp.dll!desktop::Desktop::Main() Line 1635
> 	at c:\lo\core\desktop\source\app\app.cxx(1635)
> vcllo.dll!ImplSVMain() Line 200
> 	at c:\lo\core\vcl\source\app\svmain.cxx(200)
> vcllo.dll!SVMain() Line 239
> 	at c:\lo\core\vcl\source\app\svmain.cxx(239)
> sofficeapp.dll!soffice_main() Line 169
> 	at c:\lo\core\desktop\source\app\sofficemain.cxx(169)
> soffice.bin!sal_main() Line 48
> 	at c:\lo\core\desktop\source\app\main.c(48)
> soffice.bin!main(int argc, char * * argv) Line 47
> 	at c:\lo\core\desktop\source\app\main.c(47)
> soffice.bin!WinMain(void * _hinst, void * _dummy, char * _cmdline, int _nshow) Line 47
> 	at c:\lo\core\desktop\source\app\main.c(47)
> soffice.bin!invoke_main() Line 107
> 	at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(107)
> soffice.bin!__scrt_common_main_seh() Line 283
> 	at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(283)
> soffice.bin!__scrt_common_main() Line 326
> 	at f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(326)
> soffice.bin!WinMainCRTStartup() Line 17
> 	at f:\dd\vctools\crt\vcstartup\src\startup\exe_winmain.cpp(17)
> kernel32.dll!BaseThreadInitThunk()
> ntdll.dll!RtlUserThreadStart()

... so the problematic part is the SwCursorShell::EndAllTableBoxEdit being not wrapped into some guard like the one that was fixed in http://cgit.freedesktop.org/libreoffice/core/commit/?id=2d67042dc2f0672d1aca4784e61eb2a5d0e91e08 (see bug 95797).
Comment 68 Mike Kaganski 2018-07-26 06:22:35 UTC
https://gerrit.libreoffice.org/58034
Comment 69 Heiko Tietze 2018-07-26 10:22:01 UTC
(In reply to Mike Kaganski from comment #68)
> https://gerrit.libreoffice.org/58034

:thumbs-up:
Comment 70 Commit Notification 2018-07-26 15:43:19 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#41063: don't jump to cursor when saving

It will be available in 6.2.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.