Created attachment 187706 [details] Demo Document with a table When a table contains rows where some columns have joined rows, table row selection via mouse at the left side of the table ("right arrow") behaves unexpected: In the sample document the first row's first column consists of three joined rows. Trying to select he first "optical row" by positioning the mouse where the text is (i.e.: in the second "line") selects nothing. Instead you have to move the mouse to the first "line", and then the *whole* first cell with three "Lines" is selected. But still in the last to columns of the same "optical row" only the first lines are selected (see attached screen shot). However when you row-select the second "optical row", all three "lines" of the last two columns are selected. I think a least surprising selection behavior would be that positioning the "right arrow" anywhere withing the first cell, should select that row (first three lines), and when selecting the second row, the next two rows of the first two columns should be selected as well (to match the selection of the last two columns). I know the text is somewhat abstract, and I failed to make a screenshot where the "right arrow" is visible, but the screenshots should help understanding.
Created attachment 187707 [details] Trying to select the first row using the "right arrow" Aligning the "right arrow" vertically with the text of the first cell selects nothing.
Created attachment 187708 [details] Selecting the first table row Selecting the first row does not select all "lines" that make up the "optical row".
Created attachment 187709 [details] Selecting the second tbale row Selecting the second table row does not select all "lines" that make up the "optical row".
Ulrich, I can confirm the behaviour with Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded Steps: 1. Open attachment 187706 [details]. Excluding the heading this table contains 12 rows (in some columns 3 rows have been merged. 2. Place mouse cursor left from table and left from first row and click. Result: Merged cells are selected and first row 3. Place mouse cusor left from table and left from second row and click. Nothing happens (Unexpected; My expecation: at least second row should be selected); same with third row 4. Place cursor left from table and left from fifth row and click. Result: Fifth rom is selected (O. K. for me) So I think there is a bug or at least the need for an enhancement cc: Design-Team for further input and decision about expected result
Kind of duplicate for bug 143848. I wonder how consistent such the selection can be. Assuming B1:B2 and C1:C3 is mergeded vs. A1:A3, B2:B3 - what should happen when you select A1 in these scenarios? Microsoft Word selects the virtual row of the merged cells in these cases but only if cells are empty. If filled, the selection extends to the content. And ultimately it works the same as with Writer.
Created attachment 187980 [details] Comparison MSO vs. LO (In reply to Heiko Tietze from comment #5) > Kind of duplicate for bug 143848. bug 43848 of course Attached a screencast comparing MSO vs. LO
Created attachment 189561 [details] Narrated screencast demostrating the inconsistent selection behavior If the issue description is not entirely clear to you, please watch this narrated screencast for a demonstration (recorded on Linux, with Writer 7.6.0.3 gtk3 VCL)
Okay, let's make this a bug. Selection on merged cells can be done only at the top row.