Apache OpenOffice (AOO) Bugzilla – Issue 124959
Table: Selection inconsistence for merged cells
Last modified: 2019-05-21 17:27:19 UTC
Created attachment 83449 [details] Sample Document with instruction You will find steps how to reproduce with "AOO 4.0.1 – German UI / German locale [AOO401m3(Build:9712) - Rev. 1520285 2013-09-05 13:52:01]" on German WIN7 Home Premium (64bit)", Common 4.0 User Profile in attachment Additional Info: ---------------- (a) For selection vertically merged cells are handled as the most top former cell. That causes strange unintuitive effects as described in "Issue 118681 - selecting whole table with merged cells not possible" (b) For selection of horizontally merged cells are handled as the most distant from selection start point former cell (c) Kingsoft Writer makes the same difference between horizontally and vertically merged cells. (d) Softmaker FreeOffice Writer does selection with merged cells always as I would expect: Maximum selection for area covered by merged cells.
Created attachment 85018 [details] successful replication & generalization of the bug Comment: Scenario 1: User would visually expect a select from (1,1) to (5,5) to include all cells in the range, even if cell (4,5) & (5,5) are merged together. But instead, this bug causes the selection to miss cells (5,1), (5,2), (5,3), (5,4). The user does not expect such a behavior. Scenario 2: Also, instead of (4,5)&(5,5), the cells merged are (5,4)&(5,5), this bug doesn’t show up. Hence, if the user experiences this scenario ahead of the previous one, he/she would see an inconsistency within the product. WRT attachment & 124153 The delete column operation combined with horizontally merged cells results in an unexpected result (data loss). But, delete row combined with vertically merged cells did not cause any trouble. This might be because, the merged cell is considered to include all included cells in case of horizontal merge. But not considered in case of vertical merge. Hence, the possible reason for failure in Scenario 1.
Successfully reproduced with "AOO420m1(Build:9800) - Rev. 1692551" on Win 8.1 Enterprise.i
Configuration: OS: Windows 10 Pro (64-bit) Hardware: 16GB of ram, Intel I75820k Version: AOO420m1 (Build:9800) - Rev. 1692551 First I was able to first replicate the bug with sample document provided. For the tests that follow I used a new document each time. Test 1: (Vertical cells merging) - Created an 8 x 8 table in writer. (Actual table is 9 x 9 but the top row and left column are used for numbering, as to make it easier to read) - Combined 3 cells from (5, 2) to (5, 4) - Tried selecting (1, 2) to (5, 4), this leads to expected results: the cells (1, 3) to (4, 4) are not selected. - This time I tried selecting (1, 4) to (5, 2). This in theory selects the same rectangle as I tried before. But this time it selects everything including previously not selected cells. Test 2: (Horizontal cell merging) - Created the same table as in test 1. - Merged cells from (3, 4) to (5, 4) - Selecting cells from (2, 2) to (5, 4) selects the entire rectangle. Test 3: - Created the same table as in test 1. - This time I tried merging different number of cells vertically. I tested ranges 2 to 8, but the behavior seems consistent across all of them. - I will describe a test I did with 4 merged cells. In this case it was cells from (4, 1) to (4, 4) - I selected cell (8, 8) for being non adjacent to the merged cell. - Then I selected the merged cell by mouse. - I tried navigating the table with arrow keys at point. - When selection came by mouse from a non-adjacent cell, movements to either side resulted in selecting the topmost adjacent cells on either side. In this case (3, 1) and (5, 1). - However if I selected the merged cell with arrow keys from adjacent cell to either of its side it “remembers” it. More specifically the row it got selected from. - Navigating to either side from this point onward selects the same row. For example: - If I was on cell (3, 2) - Then moved right to the merged cell using the arrow keys. - Then tried to move right again using the arrow keys. The cell that gets selected is (4, 2). - This happens on every cell adjacent to the right or left of the vertically merged cell. Test 4: Was done with same principle as test 3 but to test horizontally merged cells. The difference I have found is that when trying to navigate up or down from horizontally merged cell with arrow keys it always moves you up or down to the center of all adjacent cells on that side. For Example: - Same table as properties as in test 1. - Merged cells from (3, 3) to (5, 3) - Select non-adjacent cell with mouse - Select merged cell - Move up or down with arrow keys - The selected cells will be (4, 3) or (4,5) - Navigate to cell (3, 3) with arrow keys or mouse - Move down to the merged cell with arrow keys - Move back up. Selected cell is (4, 3). For navigating up or down from a horizontally merged cell selects the center cell in every case and moves accordingly (in case of even number of merged cells it takes the right of the two cells in the center). While navigating horizontally from a vertically merged cell depends on how the cell was selected in the first place. If selected from either sides it remembers the row, if from top/bottom or any non-adjacent cell it will simply select the topmost cell. Test 5: - Same table as in test 1 - Merged cells from (4, 1) to (4, 6) - Selected cells from (2, 1) to (5,1) - Selected cells from (2, 1) to (5,2) - Selected cells from (2, 1) to (5,3) - In every case it selects the correct number of rows on either side of the merged cell. The merged cell is also selected. (Screenshot included: Test5_A) Test 6: Same principle as in test 5 with horizontally merged cells. Observed same results as in test 5. (Screenshot included: Test6_A) Comments: I was able to confirm the inconsistency present in selecting merged tables. From what I can tell horizontally merged cells seem to be more consistent with selection.
Created attachment 85348 [details] Screenshots to accompany the follow up tests
Created attachment 86672 [details] the behavior for the selecion of horizontal merged cells is not consistent Configuration: PC OS: Windows 10 Home (64-bit) PC Hardware: cpu - Intel I7-7700HQ, ram - 16GB OpenOffice Writer Version: Apache_OpenOffice_4.5.0_Win_x86_install_en-US_1858512.exe First, I was able to reproduce the selection inconsistence for vertical merged cells and horizontal merged cells. Second, I did follow-up test and found out that even for the selection of horizontal merged cells, the behavior is not consistent. For detail, help to refer to the attachment horizontal_test_20190405.odt. Comment: Besides the “selection inconsistence for vertical merged cells and horizontal merged cells” reported in this issue, my follow-up test shows that even for the selection of horizontal merged cells, the behavior is not consistent. For the selection of horizontal merged cells (horizontal_test_20190405.odt), in test scenario 1, 2.2 and 3.3, the horizontal merged cell has been selected. But in test scenario 2.1, 3.1 and 3.2, the horizontal merged cell has not been selected.
Already reported *** This issue has been marked as a duplicate of issue 118681 ***