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
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 Can you please contribute a sample document and a step by step instruction like 0. open document 1. Click A27 2. do this 3. Do that Expected: xxxxx bcause yyyyyyy Actual: zzzz Please contribute Help texts or similar foy aour assumptions like "You should end with no selected cells"
(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).
[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.
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.
<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.
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.
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT *Update the version field *Reply via email (please reply directly on the bug tracker) *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
Bug is still there with 4.3.6.2 and 4.4.2.2 on Windows and is still annoying at least me.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Bug is still present with 5.1.5.2 and 5.2.2.2 on Windows.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.
Dear Norbert Scheibner, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
I know old bugs are boring, but it is still reproducible in 6.2.5.2.
Bug is still there with 7.1.2.2 on Windows64. The bug report makes it's 10 anniversary in 8 months.
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
I see no difference if my test is applied to horizontal ranges instead of vertical ranges.
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
Reproducible with: Version: 7.6.4.1 (x64)