Bug 78534 - CTRL+SHIFT+ARROW selection broken
Summary: CTRL+SHIFT+ARROW selection broken
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: Other All
: medium major
Assignee: Not Assigned
Whiteboard: target:4.3.0
Depends on:
Reported: 2014-05-10 17:15 UTC by OfficeUser
Modified: 2014-05-15 07:04 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

spreadsheet (11.96 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-05-10 17:16 UTC, OfficeUser

Note You need to log in before you can comment on or make changes to this bug.
Description OfficeUser 2014-05-10 17:15:50 UTC

- open the attached spreadsheet
- Click the "1" on the left side so that the whole row 1 is selected
- While holdig doen SHIFT+CTRL click arrow-down

Result: The whole spreadsheet is selected.

Expected result: Row 1 to 5 should be selected.

This is a regression. Found in...
Build-ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8libreoffice
Comment 1 OfficeUser 2014-05-10 17:16:33 UTC
Created attachment 98824 [details]
Comment 2 OfficeUser 2014-05-10 17:17:43 UTC
- While holdig down SHIFT+CTRL click arrow-down
Comment 3 OfficeUser 2014-05-10 17:45:03 UTC
Sorry guys,

but "release" is a shame!

After trying 3 minutes I found two regressions. This one and Bug 78535.
Comment 4 Cor Nouws 2014-05-10 19:47:53 UTC

Sorry, but I can't download your attachment.

I know that the selection behaviour has changed over the past time wrt position of the selected cell and the other cell with content, that you aim to reach with Ctrl+Arrow... (old > new > old - IIRC) 

Prolly what you notice is a result of that?

Can you describe the spreadsheet?
Comment 5 Jacques Guilleron 2014-05-10 20:34:37 UTC
Hello OfficeUser, Cor,

I reproduce this behaviour with LO too on Windows 7 Home Premium.
I don't reproduce with LO
In LO, we can see the issue.
I didn't tried others versions.

@Cor: spreadsheet has : A,B,C,D,E in column A.

Comment 6 m.a.riosv 2014-05-10 21:03:58 UTC
I think this is a duplicate of https://bugs.freedesktop.org/show_bug.cgi?id=42535

Please if you are not agree, reopen it.

*** This bug has been marked as a duplicate of bug 42535 ***
Comment 7 OfficeUser 2014-05-11 17:21:36 UTC

I don't agree. This bug is about that the selection does not stop at the end of the filled range.
As long as we don't know if both bugs have a common root cause, this one should be kept open.

I think this bug is a regression introduced in build while bug 42535 is an old one.


The content is:
Comment 8 Kohei Yoshida 2014-05-12 00:41:58 UTC
Turn off "Use legacy cursor movement behavior when selecting".

I'm not responsible for this change.  That said, this behavior change was intentional.
Comment 9 Jacques Guilleron 2014-05-12 22:17:02 UTC
Hi all,

This report can be closed as NOTABUG, since, as Kohei said it, the usual behaviour can be found again by a user.


Comment 10 OfficeUser 2014-05-13 20:50:02 UTC
Hi Kohei,

thank you very much for you explanations

Now I understand that it is not a regression from 4.2.3 build. It has been changed in an older build than 4.2.3.

But nevertheless...

The "old" behavior with the moving cursor was not a good solution. But it was intuitive to use after on has understood that the moving cursor is the the location, where empty/filled cells are detected when resizing the selection.

The "new" behavior does not move the cursor. It uses the cell on the other side which has no cursor or any other display, that it is the "sensing" cell when resizing the selection.

This "new" solution is absolutely not what a user expects. It is a regression in usability. IMHO it IS a bug, because it uses a non-highlighted cell only to detect empty/filled cells.

Best solution is what Excel has. It detects empty/filled cells over the full range independent where the selection has started.

As long as we don't have a proper solution like Excel, we should fall-back to the "old" behavior as soon as possible.
Comment 11 Kohei Yoshida 2014-05-14 02:55:34 UTC
So, I changed the default setting of that aforementioned option to off by default for 4.3, which is the behavior as of 4.1.

This is the commit.


For the record, Turning the legacy behavior on by default was not my intention. (heck I didn't even like that behavior but some users insisted on it and a patch was submitted).
Comment 12 Kohei Yoshida 2014-05-14 02:56:09 UTC
I'll keep this on me for now.
Comment 13 OfficeUser 2014-05-14 20:19:20 UTC
Hello Kohei,

thank you very much for this decision.

But there are two open questions remaining:

This option has not effect, at least not in build I always have the "new" fixed-cursor selection method. Also re-starting the frame work does not help.
==> Reopened.

Is there already an issue filed, where a proper "new" fixed-cursor selection method is requested, which is sensing for empty/filled cells over the full range like Excel does?
Comment 14 Kohei Yoshida 2014-05-14 20:26:54 UTC
Dude. I said this will be in 4.3.  We can't fix it for 4.2.  You already know what option to change in 4.2.

It's not appropriate to discuss 2 here.  Do it somewhere else.

Please don't reopen this any more.
Comment 15 OfficeUser 2014-05-14 20:47:22 UTC
Kohei, please read comments carefully.

I understand that you have changed the DEFAULT for 4.3.

But what I'm saying is that the option which is already present in 4.2 does have no function!!!!
Comment 16 OfficeUser 2014-05-14 20:52:45 UTC
... also with legacy selection turned on I have fixed-cursor selection.
Comment 17 OfficeUser 2014-05-14 21:51:25 UTC
After these discussions I have filed a new bug 78711 to request finally a better solution for CTRL+SHIFT+ARROW selection.

*** This bug has been marked as a duplicate of bug 78711 ***
Comment 18 OfficeUser 2014-05-15 07:04:02 UTC
Fixed by Kohei's changes. Not a duplicate.

Sorry guy, I was confused a bit.