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>.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I can reproduce with 3.5.0 beta 2.
By the way, this bug is registered in Ubuntu at: <https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/248870>
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?
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?
** 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 (4.4.1.2 or later): 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) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-03-03
(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
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.
You can't set your own bug report to new. It must be independently confirmed. Thank you for your understanding.
Requesting UX to get involved. I maintain that I think it is not a bug. Best regards. JBF
For what it's worth, MS Word does not jump to the table after saving. Win 8 32-bit MSO 2013
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
*** Bug 92365 has been marked as a duplicate of this bug. ***
*** Bug 92864 has been marked as a duplicate of this bug. ***
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.
+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
Yes saving shouldnt cause the view to jump to wherever the cursor is.
*** Bug 93440 has been marked as a duplicate of this bug. ***
Also reported in Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799428
I previously did not have this issue, it started with LO 5.0.1.2. Using Ubuntu 14.04.
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!
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)
Updated to Version: 5.0.3.2 today, the problem persists. VERY annoying.
*** Bug 95797 has been marked as a duplicate of this bug. ***
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.
Migrating Whiteboard tags to Keywords: (needsDevEval, topicUI) [NinjaEdit]
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.
*** Bug 97730 has been marked as a duplicate of this bug. ***
*** Bug 97780 has been marked as a duplicate of this bug. ***
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.
It also happen when you do a save.
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).
Nobody gave a version number in which it worked differently, so it is not a regression. Keyword regression removed. Best regards. JBF
about regression, see comment 30
(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?
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.
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
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.)
(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.
(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.
*** Bug 94663 has been marked as a duplicate of this bug. ***
(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?
(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
I undid the duplication of bug 95797. Let's keep it as the regression from 4.4.7.
(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.
I got on this thread because I entered as a bug something that seems to have been a duplicate or whatever and merged. Here is the thing. I have a document, currently 700+ pages. I have auto save on 5 minutes so I don't lose changes. Relatively frequently, I am paging thru, looking for misspellings or improper syntax .. whatever. Auto save. Now, I have no clue where I was when it occurred. By the time you manage to get back .. what the heck was I doing. Finally, you catch up.. restart the scrolling .. Auto save. Damned irritating. My comment has nothing to do with tables.
(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.
I just want to add my support for this as big - unexpected behaviour. I have it on windows in 5.1.3.2 In this version the behaviour occurs irrespective of positioning the curson in a table or outside a table. Expected behaviour would be for the current view to remain unchanged when the file is saved or autosaved. If the user has scrolled away from the cursor position, the view SHOULD NOT jump back to the cursor position as it is very distracting.
Since there are people who find this "view-jumping" to be the expected behaviour, and then there's the rest of us who don't want save/autosave to have any effect on the view, maybe this should be implemented as a configurable option? Anyway, adding my voice to the opinion that current behaviour is a bug (and an annoying one at that). Using version 5.1.3.2 on Mageia 5 (x64).
*** Bug 100059 has been marked as a duplicate of this bug. ***
*** Bug 96005 has been marked as a duplicate of this bug. ***
@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?
I, as the original reporter, am clarifying this bug title to differentiate it from the apparent regression bug 95797.
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.
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.
(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.
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?
*** Bug 105506 has been marked as a duplicate of this bug. ***
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.
(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.
(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).
(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.
*** Bug 114729 has been marked as a duplicate of this bug. ***
(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.
I'm reading a document that I'm writing. When I press CTRL+S to save, Writer takes me to the cursor, loosing my reading flow... why? I didn't order any movement (I didn't press any arrow or letter to write, etc.), so why would Writer takes me to the current cursor position? It would be great if this can be fixed, just save and nothing else. Nothing needs to change in the user view. Thanks
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
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).
https://gerrit.libreoffice.org/58034
(In reply to Mike Kaganski from comment #68) > https://gerrit.libreoffice.org/58034 :thumbs-up:
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.
Hi, I am running LibreOffice 7.1.1.2 10(Build:2), under Arch Linux, and this issue is still there. I wonder if the patch never made it into an official release, or whether this is a regression. Please let me know if you need more info.
(In reply to Manolo Martínez from comment #71) > Hi, I am running LibreOffice 7.1.1.2 10(Build:2), under Arch Linux, and this > issue is still there. I wonder if the patch never made it into an official > release, or whether this is a regression. Please let me know if you need > more info. As the fix was such a long time ago and this has a ton of comments, it is best for you to open a new report. Please include the info from your Help - About by clicking the copy button.
(In reply to Manolo Martínez from comment #71) Please do not reopen an issue that was closed long ago. If you see something similar in current versions, please file a *new* bug report; you may put this bug to "See Also" in your new bug report. Don't forget to attach a sample document, and provide *detailed* steps (including where to type what to edit, and where to position the cursor to see the problem). Thanks!