Suppose you have a document open with many comments, and possibly other navigator entries, so that there's room to scroll both up and down from the middle of the list of comments. Now, 1. Open the navigator in the side-bar. 2. Scroll so that the middle comment is at about the center of the navigator tree view. 3. Select some comment near the middle. 4. Right-click the comment, and Delete it Expected behavior: One additional item now fits into the bottom of the Nabigator tree view; existing items do not move/change position. Actual behavior: The Navigator is re-scrolled so that the item (comment) just before the one you deleted is now selected, and is at the top of the tree view with no items visible above it. This is not useful, and disorienting.
Would you mind to add some doc demonstrating the problem? Makes live easier.
Created attachment 179332 [details] Document for reproducing the bug In this document, scroll so that, say, comment 02 is the first visible, then right-click comment 08. Now, comment 07 will be the first visible.
Created attachment 179367 [details] Screencast Nothing happens on right click. But if you delete an entry, comment here, the tree is rebuilt. What exactly is scrolling in your case? Version: 7.3.2.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 8; OS: Linux 5.17; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US 7.3.2-1 Calc: threaded
(In reply to Heiko Tietze from comment #3) > Nothing happens on right click. Indeed. > But if you delete an entry, comment here, > the tree is rebuilt. What exactly is scrolling in your case? Like I said: Before deleting, comment 2 was the first one visible (because we scrolled manually to that position); after deleting, scroll-down happens so that comment 7 is the first visible. Just to clarify: I'm referring to numbered comments in the attached document, not on this bug page.
I've notice this also. It seems to be vcl backend dependent. Eyal, I'm guessing you are using gtk3? SAL_USE_VCLPLUGIN gen and qt5/kf5 don't scroll the next entry to the top after delete like gtk3 although there is also disruptive movement for them as well. Here is one way to make the position not scroll after delete: https://gerrit.libreoffice.org/c/core/+/132691
(In reply to Jim Raykowski from comment #5) > Eyal, I'm guessing you are using gtk3? Unfortunately, yes: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: fb9270b238cba4f36e595c5d7f4d85f6f3f18e1c CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US Are there nightly Qt builds for Linux? > Here is one way to make the position not scroll after delete: > https://gerrit.libreoffice.org/c/core/+/132691 Ok, but... I don't build my own version, I'm just a QA monkey, using releases and nightlies.
(In reply to Eyal Rozenberg from comment #6) > Are there nightly Qt builds for Linux? For me, nightly builds are put in /usr/local/bin. Command line 'SAL_USE_VCLPLUGIN=gen /usr/local/bin/<name of nightly build>' will use VCL: x11 In order to test using qt5 backend you will need to install the libreoffice-qt5 package, for kf5 install libreoffice-kf5 package. SAL_USE_VCLPLUGIN=qt5 or SAL_USE_VCLPLUGIN=kf5 in place of SAL_USE_VCLPLUGIN=gen above. > Ok, but... I don't build my own version, I'm just a QA monkey, using > releases and nightlies. Patch should be in today's nightly.
Unsure why the patch merged message didn't show up here. Marking as resolved fixed. Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: efe854bf9b6daff3d0ecf6e3d04bd9a50bfaa3f3 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
It's ok now, thanks Verified with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 8279d89d6e037def78f50c72fab2116ca56bef52 CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded