Description: In Writer, if you have a long table with a lot of rows, they may exceed the current view of your window (unless you’re zooming out a lot). Then, trying to select several rows with your mouse, line by line, until you reach and exceed the end of the current view will cause an unexpected behaviour: the starting row is excluded from the selection. This bug is shared with OpenOffice and still relevant in LibreOffice 7.X branch. Easy workaround: using the keyboard (Shift + Bottom arrow key) instead of the mouse to select the rows. Steps to Reproduce: 1. Create a table in Writer with more rows that the current view can display. 2. Select with the mouse one entire row. 3. Keep left-clicking and drag the cursor to the bottom of the window, selecting all the rows until it reaches the end of the current view and scrolls to the next row. Actual Results: The starting row is automatically unselected. Expected Results: The starting row should still be selected, like the other ones. Reproducible: Always User Profile Reset: Yes Additional Info: Version: 7.5.9.1 (X86_64) / LibreOffice Community Build ID: 50(Build:1) CPU threads: 6; OS: Linux 6.1; UI render: default; VCL: kf5 (cairo+xcb) Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR Debian package version: 4:7.5.9~rc1-1~bpo12+2 Calc: threaded
Created attachment 191760 [details] Animated image of the unexpected behaviour. A picture is worth a thousand words: the starting row is excluded from the selection when the cursor reaches the end of the current view.
I can't reproduce with: Version: 7.5.9.2 (X86_64) / LibreOffice Community Build ID: cdeefe45c17511d326101eed8008ac4092f278a9 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Not reproduced. Arch Linux 64-bit, X11 Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 950af5a45723d16cc5e91324f021a2e77470f2ce CPU threads: 8; OS: Linux 6.7; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 18 January 2024
I was unable to reproduce the same behavior in Version: 24.2.1.2 (X86_64) / LibreOffice Community Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Confirm 1. Insert a page filling table 2. Select rows by 'select row' feature. So by hovering at the left table border until the select row arrow appears 3. Drag down. It will unselect the first row Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: aef28c23adc87b8e26eacb56c7dbcf652e907fb9 CPU threads: 8; OS: macOS 14.3; UI render: Skia/Raster; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
(In reply to Telesto from comment #5) > Confirm > 1. Insert a page filling table > 2. Select rows by 'select row' feature. So by hovering at the left table > border until the select row arrow appears > 3. Drag down. It will unselect the first row Yes, I reproduce now: the first row is deselected after a small delay once my cursor goes above the bottom toolbar / the status bar. In OOo 3.3, the selection progressively reduces by deselecting more and more rows as long as the cursor is off-canvas. It's as if Writer deselects instead of moving the canvas down. Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bdf3b5ce49b0e4ee1b4525d344cfb037ef473059 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3
Ah, already tracked in bug 126377. *** This bug has been marked as a duplicate of bug 126377 ***