Summary: | Calc: Select to block margin is severely broken | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | crxssi |
Component: | Calc | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | critical | CC: | jmadero.dev, tmacalp |
Priority: | high | ||
Version: | 3.5.7.2 release | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | ||
Attachments: |
Correct behavior illustration-odg
Correct behavior illustration-pdf Broken behavior illustration-odg Broken behavior illustration-pdf |
Description
crxssi
2013-02-27 00:17:56 UTC
Created attachment 75608 [details]
Correct behavior illustration-odg
Correct behavior illustration-odg
Created attachment 75609 [details]
Correct behavior illustration-pdf
Correct behavior illustration-pdf
Created attachment 75610 [details]
Broken behavior illustration-odg
Broken behavior illustration-odg
Created attachment 75611 [details]
Broken behavior illustration-pdf
Broken behavior illustration-pdf
After studying this problem with some coworkers, we determined what we think the root of the problem is- When you have select activated ( <shift> ) and move the cursor in any manner, the active cell is not moving, it is staying at the starting location of the selection process. This is a radically different (and broken) behavior. What is expected is that when you move during a selection, the active cell moves. Example One: * Click on cell A1 * Press and hold <shift> * Now press <right> * Note the active cell (the cell with the bold border outline) is still A1 and not B1 as it should be. You can also see the broken behavior with the mouse. Example Two: * Click on cell A1 * Drag out a selection with the mouse by holding down the first button. * Without letting go, notice that the active cell (the cell with the bold border outline) is still A1 and not the cell where the mouse cursor is/was located, as it should be. * When you let go of the mouse button, it is still showing the wrong cell as active (the start of the selection instead of the end). This above behavior explains why the <shift><control> behavior is also broken. When you activate <control>, it is looking at the data in the row or column of the *ACTIVE CELL*. Since the active cell is not moving properly with the keyboard arrow keys during a selection ( <shift> ), it is looking at the wrong column or row and responding the wrong way. We also found a workaround for the problem, it is a different way of trying to select regions of data, but it is too complex right now for me to try and explain without a visual attachment. Another coworker pointed out that this will also break already previously recorded macros. Those macros would have expected the active cell to be at the end of a selection, not the beginning. It will also break macro compatibility between LibreOffice and OpenOffice. I can confirm this bug using LibreOffice 3.4.3 on Windows XP and LibreOffice 3.6.5.2 on an up-to-date Arch Linux install. This is really bad. It completely changes the behavior of that function in a way that severely interrupts my workflow. It also would break any macro using any of the "select to XXX block margin" commands. Maybe I'm missing something, but I don't see how something so fundamental to basic spreadsheet navigation could change in such a dramatic way without drawing more attention. New info as obtained by reading Bug 54679 I now speculate that the changes made to the cell indicator moving with Shift-arrow were intentional to better emulate Excel and Gnumeric. I can confirm that with Gnumeric, range selection does NOT move the active cell selected, which matches the changed/current LibreOffice 4 behavior. HOWEVER, Gnumeric (and presumably Excel) do NOT have a problem with Shift-Control-arrow behavior like LibreOffice 4.0.X does. This indicates someone probably made a haphazard change to the Shift-arrow behavior in LibreOffice without testing or considering that this would completely screw up Shift-Control-arrow behavior (which is described in detail in above postings). There is still no question this is a severe regression bug, but it does put a new twist on understanding how it happened to come about. No change in LO 4.1. It is still very irritating for my users. :( *** This bug has been marked as a duplicate of bug 37230 *** |