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.
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 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
(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 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).
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 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
@Eike, I thought you might be interested in this issue...
Eike Rathke committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/25160a56f4fd8a18c27eaa77b0539ab267b80294 Resolves: tdf#122232 Move TabStartCol logic to ScTable::GetNextPos() It will be available in 6.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review https://gerrit.libreoffice.org/82536 for 6-3
Verified in Version: 6.4.0.0.alpha1+ Build ID: 26b7ff2b6cc4def8ff7b02e223961534ba88e654 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Eike, thanks for fixing this issue!!
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/commit/19ed10018a4e92209a2e3445a2792f7033eb366f Resolves: tdf#122232 Move TabStartCol logic to ScTable::GetNextPos() It will be available in 6.3.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Zdeněk Crhonek committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/01a3a7cee2dc680910f4ddec004724b89a81099b uitest for bug tdf#122232 It will be available in 6.5.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/bfee21b6c87c420e0c5d3447b13e013592a30c22 tdf#122232: move UItest to CppunitTest It will be available in 7.0.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.