Bug 45472 - EDITING: Cursor position is miscalculated after selecting cells
Summary: EDITING: Cursor position is miscalculated after selecting cells
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shortcuts-Accelerators
  Show dependency tree / graph
 
Reported: 2012-01-31 17:04 UTC by Norbert Scheibner
Modified: 2022-11-16 19:51 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Attachments
Sample file with 7 cases. (13.43 KB, application/vnd.oasis.opendocument.spreadsheet)
2022-02-01 20:49 UTC, LeroyG 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Norbert Scheibner 2012-01-31 17:04:06 UTC 
Some contiguous cells with content in a row (if in a line it's the same). Go to the last cell in that row. Press CTRL-SHIFT-UP to select all contiguous cells in that row from that last one to the first.

If You are pressing CTRL-DOWN You should end with no selected cells and the cursor
should be at the last of the contiguous cells with content or at the next cell with content below or at the last cell in that row, but You end up that number of lines under the last cell, which is the number of selected cells before minus 1.

If You press CTRL-UP instead You should end with no selected cells and the cursor in the first of the contiguous cells, which does not work also, but I didn't get the logic behind. It makes a difference if the number of selected cells is even or not and if the first cell is in line 1.

For lines and CTRL-LEFT or CTRL-RIGHT it's the same and if You start the selection in the first of the contiguous cells, You can see similar behavior.

I don't know the first version which didn't work that strange, but the OOo 3.1.1 I have here at the moment works correctly as expected.

As far as I can see, is this hardware and OS independent.

Glück Auf
    Norbert
Comment 1 Rainer Bielefeld Retired 2012-01-31 23:14:09 UTC Comment hidden (obsolete)
Comment 2 Norbert Scheibner 2012-02-02 15:20:46 UTC 
(In reply to comment #1)
> HI Norbert, thank you for your report, unfortunately it contains too many "If",
> "Should", "but", "or"so I am not sure whether I understand it

Sorry, I'll try. Tell me if I made that clear now.

Example 1:
1. open new spreadsheet
2. fill C11 to c18 with content
3. click C18
4. press SHIFT-CTRL-UP
5. press CTRL-UP
--- cursor is in c8 but should be in c11

Example 2:
...
4. press SHIFT-CTRL-UP
5. press CTRL-DOWN
--- cursor is in c25 but should be in c18

Example 3:
1. open new spreadsheet
2. fill k11 to z11 with content
3. click z11
4. press SHIFT-CTRL-LEFT
5. press CTRL-LEFT
--- cursor is in p11 but should be in k11

Example 4:
...
4. press SHIFT-CTRL-LEFT
5. press CTRL-RIGHT
--- cursor is in ao11 but should be in z11

These examples start with the selection in the last of the contiguous cells with content (c18 and z11). The other direction is broken too (starting in c11).
Comment 3 Rainer Bielefeld Retired 2012-02-04 12:30:59 UTC 
[Reproducible] with "LibreOffice 3.5.0 RC3 German UI/Locale [Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735] on German WIN7 Home Premium (64bit) 

Some Details Example 1:
Wiht a.m. Version and 3.4.5 I reach C4, C8 reached with 3.3.0
Very old issue, also in OOo 3.1.1, OOo 1.1.4 ;-)
Doing the same but C11->C18 is even worse, LibO 3.3.0 reaches row 1048569 , 3.4.5 row 1048566

Some Details Example 2:
Reproducible with several different wrong targets (depending on LibO version). OK with OOo 3.1.1

I believe the resting results ;-)

@Kohei:
Please feel free to reassign (or reset Assignee to default) if it’s not your area. Please set Status to ASSIGNED if you accept this Bug.
Comment 4 Kohei Yoshida 2012-07-18 23:42:13 UTC 
This is a duplicate to an existing bug, whose number escapes me at the moment.  Markus was showing interest in tackling it last time we spoke.  I'll put him in CC.
Comment 5 Rainer Bielefeld Retired 2012-07-19 04:03:45 UTC 
<http://wiki.documentfoundation.org/BugReport_Details#Version>
Reproducible with 3.3.0, OOo 3.1, inherited from OOo. I can't find the related Bug Kohei mentioned.
Comment 6 Markus Mohrhard 2012-07-19 16:23:19 UTC 
Looks like another case where the cursor navigation does something strange.

I'll try to come up with a unit test for cursor navigation soon and then will try to implement a clean implementation for cursor navigation that works correctly and is not that complicated and unmaintainable as the current implementation.
Comment 7 tmacalp 2013-04-09 20:57:24 UTC 
I just found this bug, but appears to be the same as Bug 61534 and Bug 52239.

From what I can tell, the problem is with with "selection modifying keyboard actions" no longer changing your cursor cell.  These actions include shift+arrow keys, shift+ctrl+arrow keys, etc...

Simple steps to reproduce:
1. Open a new spreadsheet
2. Press shift+right

Expected behavior:  Selection contains a1:b1 AND cursor cell moved to b1
Current behavior:   Selection contains a1:b1 and cursor cell stays in a1

The previous (correct) behavior is how it used to work, and how it still works in current OpenOffice. 

The problem is that ALL actions are based on your cursor cell, so if you start in a blank column, shift-arrow into some actual data, and then ctrl-shift-down, it will attempt to go to the bottom of the range, except that the action is still based off of the cursor cell, which is still in a blank column, so it goes to the very bottom of the range.

In bug 61534 there are many examples which explain this behavior. In my opinion, this is a serious regression, as it makes it very difficult for me to select a blank cell range parallel to a filled one.  It also has the possibility of destroying previously recorded macros.

I just don't know if this behavior was intentionally changed or if it is a regression.  Does Excel behave this way?  I don't have access to a current version to a current version of MS Office to compare. If it was intentional, I would love to at least have a toggle to enable to original (correct) behavior.

I can also verify that this is still affecting LibreOffice 4.0.2.2, both MS Windows and Linux.
Comment 8 QA Administrators 2015-04-19 03:20:08 UTC Comment hidden (obsolete)
Comment 9 Norbert Scheibner 2015-04-21 18:21:58 UTC Comment hidden (obsolete)
Comment 10 QA Administrators 2016-09-20 09:32:10 UTC Comment hidden (obsolete)
Comment 11 Norbert Scheibner 2016-10-10 21:17:47 UTC Comment hidden (obsolete)
Comment 12 QA Administrators 2018-06-11 02:34:22 UTC Comment hidden (obsolete)
Comment 13 Norbert Scheibner 2018-06-11 17:20:20 UTC 
Bug is still present with 6.0.2.1 on Windows.

I think the behavior changed a bit, but it's still not plausible and differs whether U select horizontal or vertical contiguous cells and whether U start in the upper left or down right corner of the selection.
Comment 14 QA Administrators 2019-06-12 02:58:10 UTC Comment hidden (obsolete)
Comment 15 Norbert Scheibner 2019-07-20 14:00:43 UTC Comment hidden (obsolete)
Comment 16 Norbert Scheibner 2021-06-07 18:59:58 UTC 
Bug is still there with 7.1.2.2 on Windows64.

The bug report makes it's 10 anniversary in 8 months.
Comment 17 LeroyG 2022-02-01 20:49:20 UTC 
Created attachment 177966 [details]
Sample file with 7 cases.

There is no need to fill cells, just selecting them. So, cells could be empty.

Does not matter if cells are selected with keyboard (i.e., Ctrl+Shift+Arrow Up, or Shift+Arrow Up×n) or with mouse/touchpad (click/tap and drag).

If the expected behavior is to have a similar range in which to paste, I think there is an inconsistency (cases b-c, d, e, f, h-i), because first or last final cells are not empty.

Version: 7.1.8.1 / LibreOffice Community
Build ID: e1f30c802c3269a1d052614453f260e49458c82c
CPU threads: 1; OS: Linux 4.12; UI render: default; VCL: x11
Locale: es-MX (es_AR.UTF-8); UI: en-US
Calc: threaded
Comment 18 LeroyG 2022-02-01 20:53:11 UTC 
I see no difference if my test is applied to horizontal ranges instead of vertical ranges.
Comment 19 LeroyG 2022-11-16 19:51:08 UTC 
Reproducible with:

Version: 7.3.7.2 (x64) / LibreOffice Community
Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: es-MX (es_ES); UI: en-US
Calc: CL