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.
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 18.104.22.168 on OpenSUSE 15, 64bit rpm Linux. Wasn't there with LO 22.214.171.124. There the cursor jumps from G6 to C7 as expected.
Lera, please look at this. I remember that you made some changes by this theme
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
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
(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.
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 126.96.36.199), 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 188.8.131.52. 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).
This seems to have begun at the below commit.
Adding Cc: to tagezi ; Could you possibly take a look at this one?
f24e0b81f9f6e7cdabac05f898a260d92d95956a is the first bad commit
Author: Jenkins Build User <firstname.lastname@example.org>
Date: Wed Mar 21 01:12:45 2018 +0100
author tagezi <email@example.com> 2018-02-01 13:52:49 +0300
committer Eike Rathke <firstname.lastname@example.org> 2018-03-21 01:08:03 +0100
commit 3b3e203461441da733096be323641a8dc07ff24f (patch)
parent dd4f1b1bd31daf080dc0420524712dc244e539b5 (diff)
tdf#68290 cursor moves with Enter in protected sheet
@Eike, I thought you might be interested in this issue...