Bug 122232 - UI: Pressing Enter in a protected sheet doesn't jump to next row in every case
Summary: UI: Pressing Enter in a protected sheet doesn't jump to next row in every case
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.1.0.3 release
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2018-12-20 20:13 UTC by Robert Großkopf
Modified: 2019-02-02 11:15 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Open the Calc-file and start at C6. Press return at G6. Cursor jumps to C29. (9.08 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-12-20 20:13 UTC, Robert Großkopf
Details
Test Doc where the protected cells are to the left (8.33 KB, application/vnd.oasis.opendocument.spreadsheet)
2018-12-23 23:24 UTC, Gerhard Weydt
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Großkopf 2018-12-20 20:13:20 UTC
Created attachment 147725 [details]
Open the Calc-file and start at C6. Press return at G6. Cursor jumps to C29.

Open the attached Calc-file.
Start with from C6. 
Press tabulator to reach G6.
Press "Enter".
Cursor jumps to C29 instead of C7.

Note: Column G is write protected except G6 and G29.
Column C and D aren't write protected.

This bug appears first with LO 6.1.0.3 on OpenSUSE 15, 64bit rpm Linux. Wasn't there with LO 6.0.5.2. There the cursor jumps from G6 to C7 as expected.
Comment 1 Roman Kuznetsov 2018-12-21 07:23:18 UTC Comment hidden (obsolete)
Comment 2 Durgapriyanka 2018-12-21 21:11:59 UTC
Thank you for reporting the bug. I can confirm that the bug is present, but in my case, the cursor jumps to G29 instead of C29

Version: 6.3.0.0.alpha0+
Build ID: 3c964980da07892a02d5ac721d80558c459532d0
CPU threads: 2; OS: Windows 6.1; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-12-12_02:07:45
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 3 Robert Großkopf 2018-12-22 07:58:09 UTC
(In reply to Durgapriyanka from comment #2)
> Thank you for reporting the bug. I can confirm that the bug is present, but
> in my case, the cursor jumps to G29 instead of C29
> 
It will jump to G29 when starting from G6. Could be this is intended, because all other fields of column G are write-protected: "Jump to next field, where input is possible." The behaviour here in LO 6.0 is: The cursor jumps to G7, but input isn't possible here.

It will jump on LO 6.1.*/OpenSUSE to C29 when following the description and start with Tab from C6. When starting there and pressing Enter in G6 it will jump to C29. This couldn't have been intended, because the next field for input data will be C7.
Comment 4 Gerhard Weydt 2018-12-23 23:24:56 UTC
Created attachment 147790 [details]
Test Doc where the protected cells are to the left

After confirming that I also think that the described behaviour is a bug (and it's still present in 6.2.0.1), I want to describe what I think is the intended behaviour in simpler situations, which I indeed think is helpful when filling  many rows of similar data, which might be deemed the most frequent case.
if you start from a cell, only entering data and then going to the next cell using Tab, then using Enter will position the cell cursor in the next row and in the column of the cell this sequence started with. I cannot tell exactly which actions break this sequence, but clicking in a cell and changing data does, for example.
Now the problem in the present case obviously lies in the fact that some cells are protected. It is now more difficult to identify the cell to jump to. It seems that up to 6.0 Calc first selected the column to jump to and then selected the fist cell below the starting point which is not protected. (for the moment I call this choice 1)
Starting somewhere with 6.1. the behavious changes, as described in the bug. One could assume that it now first looks for the next unprotected cell in the current column (where Enter was pressed) and the goes to the start column (taht would be called choice 2). If it were so, this would have corrected a wrong behaviour in 6.0 (and probably in former releases too) which you can test in the attachment "reverseExample.odt" (protected cells are also yellow): if C7:D10 are protected and you enter data in the sequence C6 -> D6 -> G6 and then use Enter, then the cursor is in the protected cell D7.
Unfortunately, this is not the case. The same still happens in 6.2.0.1. So it is not the case that one error was corrected by creating another, but the situation now is worse than before: both test cases now are wrongly handled, whereas only one was beforehand.
Although the present situation is doubtlessly worse than the one before and should therefore be changed, it does not seem clear to me how a complete solution could look like. Even choice 1 and choice 2 seem to be contradictory solutions, each one fitted for one type of constellations, and combinations of protected/unprotected cells more difficult are conceivable. If, for example choice 1 is used and jumps to a cell which is protected, a human being would look for the next unprotected cell to the right _which will be needed_. But this cannot be detected by the program: it selected the first cell of the new row simply because it was the first in the previous row, I assume, and I also assume that the intermittent columns used in the previous row are not available to the program. So I cannot propose a consistent way for the determination of the jump target in the general case of protected cells.
By the way: is there another jump direction in Calc for languages that write from right to left or top-down? That would make the problem even more complicate (although not necessarily more difficult, as a solution could probably be transposed).
Comment 5 raal 2018-12-24 05:32:22 UTC
This seems to have begun at the below commit.
Adding Cc: to tagezi ; Could you possibly take a look at this one?
Thanks

f24e0b81f9f6e7cdabac05f898a260d92d95956a is the first bad commit
commit f24e0b81f9f6e7cdabac05f898a260d92d95956a
Author: Jenkins Build User <tdf@pollux.tdf>
Date:   Wed Mar 21 01:12:45 2018 +0100

    source sha:3b3e203461441da733096be323641a8dc07ff24f

author	tagezi <lera.goncharuk@gmail.com>	2018-02-01 13:52:49 +0300
committer	Eike Rathke <erack@redhat.com>	2018-03-21 01:08:03 +0100
commit	3b3e203461441da733096be323641a8dc07ff24f (patch)
tree	c900fba2839cdf0bee457e68a0b79a0f78d31fce
parent	dd4f1b1bd31daf080dc0420524712dc244e539b5 (diff)
tdf#68290 cursor moves with Enter in protected sheet
Comment 6 Xisco Faulí 2019-02-02 11:15:09 UTC
@Eike, I thought you might be interested in this issue...