Bug 42535 - Editing UI: Ctrl+Shift-RightArrow faulty extension result
Summary: Editing UI: Ctrl+Shift-RightArrow faulty extension result
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 62436 132936 (view as bug list)
Depends on:
Blocks: Shortcuts-Accelerators
  Show dependency treegraph
 
Reported: 2011-11-02 14:18 UTC by David
Modified: 2020-05-11 08:09 UTC (History)
9 users (show)

See Also:
Crash report or crash signature:


Attachments
Test document with steps to reproduce inside (12.58 KB, application/vnd.oasis.opendocument.spreadsheet)
2013-07-24 11:59 UTC, sasha.libreoffice
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David 2011-11-02 14:18:38 UTC
Context:
in Calc of LO 3.4.3 on WinXP Pro

The cell range L155:AA155 contains empty cells. The cells on either end of that range are filled with numbers.

The cell above L155 contains a formula. In fact all the cells in the row above (cells ...L154:AA156...) contain either a formula or a value.

The task is to copy the formula from L154 to L155, make an edit, extend the range from L155 to AA155, Edit | Fill Right.
 
The keystokes:
In L154: Ctrl+C
Down Arrow: moves to L155
Ctrl+V: paste
Esc: terminate the "dotted border" focus on L154
F2: make the small edit
Enter: terminate the edit
Ctrl+Shift+RightArrow: SHOULD extend to AB156 where it finds the next filled cell in the row.
~~~~~~~~~~~~~~~~~~~~~: ACTUALLY extends selection to a large portion of column L. I originally thought that the faulty extension was to the entire column L.

Mr. Stephan Zeitsman of the User's Help forum subsequently observed:

"I just tried your example (after I posted my reply).  I find that the
selection is actually extended to K1:L155, which means it selects
column K and column L (but not the entire column, only up to row 155).
 This is very strange behaviour, as it actually extends the selection
to the *left*, although I pressed Ctrl + Shift + RightArrow."
 
Workaround
start as above until:
F2: make the small edit
Enter: terminate the edit
RightArrow (once): shift focus from L155 to M155
LeftArrow (once): shift focus from M155 to L155
Ctrl+Shift+RightArrow: SHOULD and DOES extend to AB156 where it finds the next filled cell in the row.
 
I use the M$ Natural Keyboard. The defective behavior results using either of the possible keys for "RightArrow": the 4-keypad "compass set" or the NumberPad (NumLock off).

Mr. Stephan Zeitsman suggested I examine these two existing bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=39212
https://bugs.freedesktop.org/show_bug.cgi?id=37230
 
I slogged through those two. I think my issue is different. I am in no way attempting or expecting my keystroke sequence to intelligently (or foolishly) emulate any behavior I have ever used in M$ Excel. 

So I respectfully report here.
--
David S. Crampton
Comment 1 sasha.libreoffice 2012-04-19 02:45:57 UTC
Thanks for bugreport
Please, attach spreadsheet that demonstrates this problem (where I can do described experiments)
Comment 2 David 2012-05-25 16:57:38 UTC
Sasha,

I have been away for a month. At this time I cannot spend more time on this bug report. I did a lot of detailed writing on it in my first submission. The problem still exists in build 402.  Others have also reported it or similar.  It was not so much spreadsheet specific as I recalled.

Sorry I can't contribute more at this time.
David

-----Original Message-----
From: bugzilla-daemon <bugzilla-daemon@freedesktop.org>
To: dcramptond <dcramptond@netscape.net>
Sent: Thu, Apr 19, 2012 2:46 am
Subject: [Bug 42535] Editing UI: Ctrl+Shift-RightArrow faulty extension result


https://bugs.freedesktop.org/show_bug.cgi?id=42535
sasha.libreoffice@gmail.com changed:
           What    |Removed                     |Added
---------------------------------------------------------------------------
                CC|                            |sasha.libreoffice@gmail.com
--- Comment #1 from sasha.libreoffice@gmail.com 2012-04-19 02:45:57 PDT ---
hanks for bugreport
lease, attach spreadsheet that demonstrates this problem (where I can do
escribed experiments)
Comment 3 QA Administrators 2013-07-18 06:15:55 UTC Comment hidden (obsolete)
Comment 4 David 2013-07-19 14:30:20 UTC Comment hidden (obsolete)
Comment 5 sasha.libreoffice 2013-07-24 11:59:28 UTC
Created attachment 82931 [details]
Test document with steps to reproduce inside
Comment 6 sasha.libreoffice 2013-07-24 12:01:29 UTC
Thanks for reply. Sorry for inconvenience.

I have attached needed document.
Reproduced problem in 4.1.0 on Fedora (RFR) 64 bit
Comment 7 m.a.riosv 2014-05-10 21:03:58 UTC
*** Bug 78534 has been marked as a duplicate of this bug. ***
Comment 8 tmacalp 2014-05-15 03:12:02 UTC
*** Bug 62436 has been marked as a duplicate of this bug. ***
Comment 9 tmacalp 2014-05-15 03:27:28 UTC
As described in bug 62436, this bug seems to stem from all "move to block margin" operations immediately following a paste being wonky.

Essentially, immediately after you paste into a cell, your next select/move to block margin operation(ctrl+arrow or ctrl+shift+arrow) will be erroneously based from cell A1 instead of the real cursor cell.

My test:
1. Start a new spreadsheet
2. Insert a number in A10
3. Select any cell (C15 in this case)
4. Copy (Ctrl-C)
5. Paste into same cell (Ctrl-V)
6. Ctrl+shift+down

Expected:
We were in C15 when we performed the select to block margin action, so ctrl+shift+down should select the range C15:C1048576

Actual:
Selects range A10:C15.  This is because it selects from the cursor cell C15 to the cell ctrl+shift+down'd from A1.  Since in step 2 we inserted a number into A10, it selects the range A10:C15.
Comment 10 kalle 2015-11-10 16:35:59 UTC
The original report is very confusing and describes a special case of an issue I've run into several times within just a few hours of using LibreOffice.

Simply put: after a Cut/Paste/Delete operation, keyboard navigation is utterly broken.

Now, I don't know who LibreOffice tries to cater to, but I'm amazed this kind of bug can exist for years. Advanced users need keyboard navigation to work!

Allow me to summarize the research:

* After Paste, if you try to modify the selection using Shift+Up/Down/Left/Right, the other end of the selection will unexpectedly jump to A1 (bug 57008, bug 68703, bug 87388).

* After Paste, if you try to modify the selection using Shift+Cmd+Down or Shift+Cmd+Right, the other end of the selection will unexpectedly jump to column A or row 1 (this bug). It may be more complicated than that — I haven't tested this extensively.

* After Paste, if you try to move to the next (but not previous) value in the column/row by hitting Cmd+arrow, the movement will overshoot by an amount that's based on the original cursor location (bug 62436).

* After Cut/Delete, if you try to move to the next *or* previous value in the column/row by hitting Cmd+arrow, the movement will over-/undershoot by an amount that's based on the size and direction of the prior selection (bug 95730).

It has been conjectured that all of these are in fact the one and the same bug. Perhaps. But it should be noted that the "Move to block margin" command can miscalculate the coordinates in three different ways depending on whether you're simultenously modifying a selection and whether the previous operation was Paste or Cut/Delete.

Also, when the selection is being modified, even basic Up/Down/Left/Right navigation is enough to trigger the jump to A1, so it's not just about "Move to block margin".

However, if these are indeed various manifestations of the same faulty arithmetic, then fixing it would likely be fairly easy and yield a huge payoff for the effort in terms of usability.

For now, I'm going back to the increasingly obsolete OpenOffice because it's just more usable.

I have tested recent and 3.3.0 versions of both LibreOffice and OpenOffice. LibreOffice has always had this bug, OpenOffice never.
Comment 11 QA Administrators 2017-01-03 19:34:48 UTC Comment hidden (obsolete)
Comment 12 OfficeUser 2017-01-04 11:22:41 UTC
Bug still reproducibly with:

Version: 5.2.3.2
Build-ID: 1:5.2.3~rc2-0ubuntu1~trusty1
CPU-Threads: 8; BS-Version: Linux 4.4; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE.UTF-8); Calc: group
Comment 13 QA Administrators 2018-01-05 03:41:55 UTC Comment hidden (obsolete)
Comment 14 David 2018-01-10 20:44:20 UTC
In 5.3.7.2 this bug continues as originally described.
Comment 15 QA Administrators 2019-10-07 03:03:38 UTC Comment hidden (obsolete)
Comment 16 Stephan Zietsman 2019-10-30 08:33:37 UTC
Just tested with version 6.0.7.3 in Ubuntu and the bug is still present as described above.

-- 
LibreOffice
Version: 6.0.7.3
Build ID: 1:6.0.7-0ubuntu0.18.04.10
Comment 17 m.a.riosv 2020-05-11 08:09:20 UTC
*** Bug 132936 has been marked as a duplicate of this bug. ***