Apache OpenOffice (AOO) Bugzilla – Issue 18014
wrong cursor position when undoing "insert table row"
Last modified: 2013-08-07 14:42:49 UTC
* open a new text document * insert a manual page break * on the second page, insert a table (arbitrary dimensions) * place the cursor in the very last cell of the table * press Tab => a new line is inserted at the end of the table * press Ctrl-Z, undoing the change this way => the line is removed (which is fine), and the cursor is positioned at the very top of the document This makes editing larger documents a little bit annoying ... another scenario: If you insert a new line explicitly (by using the respective slot in the toolbar), place the cursor in the new line, and UNO this, then the cursor also jumps to the wrong position. Seems that everytime UNDO deletes the row where the cursor is currently positioned, the new cursor position is not properly determined. Note: When deleting the row directly (via the toolbar slot), then the cursor position is correct afterwards.
targeting
sorry, wrong owner
I still see it in 1.1RC3 german version WIN98SE: 645m15(Build8669) [CWS:ooo11rc3], so I change Version. Might be a Problem of all OS? Pls check! I added oooqa and a testfile for quicktest. Problem happens for "undo" with "undo-button", too. Rainer
Created attachment 8577 [details] testfile
.
*** Issue 24641 has been marked as a duplicate of this issue. ***
estimated effort
*** Issue 24201 has been marked as a duplicate of this issue. ***
P4 => later
for the records I have to say that I do not agree to this target because: - this is a regression over 1.1 (don't we have a rule to not retarget regressions?) - Undo has been declared as major area for OOo 2.0 (see the PCD), as has usability. This bug here describes an annoying problem with the usability of Undo (try it out - in larger documents, you need *ages* to get back to the place where the cursor was before this innocent "undo" command ...)
Workaround (one I use in similar situations): Set a bookmark for the cursor location. Run undo (long right-click so you can skip undoing the bookmark). Run undo. Goto bookmark using Navigator. Remove bokmark. A lot of extra work, but less than re-locating the proper location by hand. And,yes, it is a regression. 1.1.1 does not do this.
*** Issue 28328 has been marked as a duplicate of this issue. ***
> Workaround (one I use in similar situations): Set a bookmark for the cursor > location. Run undo (long right-click so you can skip undoing the bookmark). > Run undo. Goto bookmark using Navigator. Remove bokmark. Ever tried to do this with keyboard only? The current behavior is a *major* break in the user's (okay: in my) workflow, when you're used to work with the keyboard instead of the mouse. You need ages to restore your "work environment" (the cursor position, in this case) just because of a small innocent Ctrl-Z ... :(
*** Issue 25665 has been marked as a duplicate of this issue. ***
The cursor also jumps to the top of the document when a column is removed. Marking issue 39609 as a duplicate of this issue.
*** Issue 39609 has been marked as a duplicate of this issue. ***
*** Issue 20410 has been marked as a duplicate of this issue. ***
Issue 37748 is also a duplicate of this issue, I think...
*** Issue 37748 has been marked as a duplicate of this issue. ***
I can confirm that this also happens in OpenOffice 2.0! I use Debian GNU/Linux (sid). Package openoffice.org_2.0.0-4.
*** Issue 59063 has been marked as a duplicate of this issue. ***
*** Issue 77235 has been marked as a duplicate of this issue. ***
*** Issue 77940 has been marked as a duplicate of this issue. ***
*** Issue 78777 has been marked as a duplicate of this issue. ***
This still happens with OO 2.2.1. Can you update the version? (As this is really, really an old issue and it seem that noone looks anymore at OO1.1 bugs.)
There's a rule that "Version" describes the version where this issue was first encountered, and should not be changed then. However, "Version" is usually not used when judging which issues to "fix next". Instead, votes, for instance, are important. So, lobby for the issue and get some people to vote for it. Given the number of duplicates which we collected over time, I take the liberty to increase the priority. Also, I add the keywords which I missed in the original submission.
AMA is responsible for undo know.
@ama: given the high number of votes and duplicates we should reconsider the target.
Set target to OOo2.x
*** Issue 82241 has been marked as a duplicate of this issue. ***
*** Issue 82547 has been marked as a duplicate of this issue. ***
MRU->AMA: having a look at the duplicates-tail, might it be possible to fix this in the OO2 branch?
I'll do my best ;-)
Fixed in CWS sw8u10bf02 crsrsh.cxx
Ready for QA.
Verified fix in CWS sw8u10bf02.
Checked fix in OOH680m7 and SRC680m245.
This bug is back in 2.3.1
This bug cannot be "back" in OO 2.3.1. It was fixed for OO 2.4, as everyone could see from the "Target milestone"...