Description: I noticed that the "Define Bibliography Entry" dialog has ugly scrolling behaviour on Windows, as in it the window position doesn't change unless you let go of the scroll bar or reach either end. This does not happen on Linux, the scrolling is smooth there, just as one would expect. I also noticed that it happens on many more dialogues, such as the "Print" dialog and "Extensions" manager, seems to generally happen with the GtkScrolledWindow. I tried looking into it, but didn't manage to figure it out. If you have any hints, I'd be happy to look into it deeper. Steps to Reproduce: 1. Open one of the affected windows, e.g. the "Print" dialog (Ctrl+P) on Windows 2. Try to scroll by dragging the scroll bar Actual Results: The window position doesn't change until the scroll bar is let go of or end is reached Expected Results: The scroll position should change continually while the scrollbar is dragged Reproducible: Always User Profile Reset: No Additional Info: Nothing
Please, can you test with a newer version. Versions 7.x are EOL. https://www.libreoffice.org/download/download-libreoffice/
Sorry for not being clear, 7.X is just the earliest I remember this happening. It happens all the way up to the current nightly builds.
[Automated Action] NeedInfo-To-Unconfirmed
I don't reproduce. In 7.0, neither the Print dialog or Define bibliography entry dialog is scrollable. I didn't bother to install a dozen extensions to test that dialog. Please copy and paste here the content of your Help - About by clicking the copy button. This allows us to know more about your system. Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9e3803ae438ddcf91ec0e15431be379561d28ba6 CPU threads: 2; OS: Windows 11 X86_64 (10.0 build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-GB Calc: threaded
Sure, here is the "Help - About" from the latest nightly version, which I can replicate the behaviour on, just as described: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 9e3803ae438ddcf91ec0e15431be379561d28ba6 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: en-GB Calc: threaded You're right, though, I don't seem to be able to reproduce this on the 7.0.0.1-7.0.0.3 either. I've tested couple of versions from the archive and I have to note that the scrolling is perfectly smooth for me on 7.3-7.4. The regression seems to have happened between 7.4.7.2 (can't reproduce) and 7.5.9.2 (can reproduce).
I tried doing bibisect, but I'm really not sure if I got it right. ``` win64-7.5> git bisect good 227c92f80c5c83019e3a88482d0c52ae11c8678d is the first bad commit commit 227c92f80c5c83019e3a88482d0c52ae11c8678d Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Sep 27 05:26:24 2023 -0700 source 439f487d14ce4afaa25b8aa23cf954ae2ddaeb26 source 439f487d14ce4afaa25b8aa23cf954ae2ddaeb26 instdir/program/setup.ini | 2 +- instdir/program/vcllo.dll | Bin 13096448 -> 13096448 bytes instdir/program/version.ini | 2 +- 3 files changed, 2 insertions(+), 2 deletions(-) ```
(In reply to dolezvo1 from comment #6) > I tried doing bibisect, but I'm really not sure if I got it right. > > ``` > win64-7.5> git bisect good 227c92f80c5c83019e3a88482d0c52ae11c8678d is the > first bad commit > commit 227c92f80c5c83019e3a88482d0c52ae11c8678d > Author: Norbert Thiebaud <nthiebaud@gmail.com> > Date: Wed Sep 27 05:26:24 2023 -0700 > > source 439f487d14ce4afaa25b8aa23cf954ae2ddaeb26 That commit was made originally to 24.2 and backported all the way to 7.5. However, in bug 157312 comment 19 Patrick says it had to be reverted. Later he made a change that only affects macOS. See the current state of the code: https://git.libreoffice.org/core/+/refs/heads/master/vcl/skia/gdiimpl.cxx#268 So the current behaviour you see on 25.2 or newer can't be because of this change. In any case, you may always double-check your results by doing git checkout 227c92f80c5c83019e3a88482d0c52ae11c8678d test, should be the bad result. git checkout HEAD~1 test, should be the good result. As explained here: https://wiki.documentfoundation.org/QA/Bibisect/Bibisecting_tutorial#Analysis
Yeah, that checks out, the difference is clear when I do that.
(In reply to Buovjaga from comment #7) > So the current behaviour you see on 25.2 or newer can't be because of this > change. Oh, I was inaccurate here: the reverting happened in commit 5a38e4f9798c5ff247aa57581adf2671485627fd which was merged on 10 Nov, while you tested with a build that's from 4 Nov! So hopefully if you test with a fresh daily build the issue will be gone.
You're right, the daily build behaves exactly like the commit before the 227c92f80c5c83019e3a88482d0c52ae11c8678d. Unfortunately, I noticed the issue is not fixed completely yet. In the daily build, the movement of the slider itself was smooth, but the content still lagged behind noticeably. I did another bibisect, and I found out that the issue was introduced with the dark mode (b074f4c8ea84257ffadebfc33cfe576da77892f5). More specifically, using Dark mode seems to cause the lagging. When I went back to the daily build and tried setting it into Light mode, the content scrolling is perfectly smooth again.
(In reply to dolezvo1 from comment #10) > You're right, the daily build behaves exactly like the commit before the > 227c92f80c5c83019e3a88482d0c52ae11c8678d. > > Unfortunately, I noticed the issue is not fixed completely yet. In the daily > build, the movement of the slider itself was smooth, but the content still > lagged behind noticeably. I did another bibisect, and I found out that the > issue was introduced with the dark mode > (b074f4c8ea84257ffadebfc33cfe576da77892f5). More specifically, using Dark > mode seems to cause the lagging. When I went back to the daily build and > tried setting it into Light mode, the content scrolling is perfectly smooth > again. I guess that's this from win64-7.5 repo: commit b074f4c8ea84257ffadebfc33cfe576da77892f5 Author: Norbert Thiebaud <nthiebaud@gmail.com> Date: Wed Aug 17 09:37:21 2022 -0700 source db4c4676b70bb5f9a1c169735e8fbe92b097a57b source db4c4676b70bb5f9a1c169735e8fbe92b097a57b source ee3ebda2be3965584d12b52c007fb047d624b64c source f61ea9d2d8d61fe190aa43a57b2316def6c12b8d source af87ec3137c32ba098c072304595d8b590f3447c source d9655727ac688753ea12aaedc09a006134dd4a13 source fad0cb2fba8b3d41fe8b12659ba0cf63c89aa90e source a86dd4df616227ed7e7be911653dac06973d8e25 source 6b6e044e05d272d89095b7f05f863c31da0da784 source 3d0f3a1a6fdc677507a8274e5882aca26cf98a22 source 1a7f79d6ceab9871511758682efb677483437a87 source 36e1834c9893deae9a45cd2026eb7d02e6a16bd9 source 996ded6b42c924124f279a20a10a67754df80a8a source 8575177e240f85850a3b9d27d41a61b3c5445fc7 source d40bfecddcac38006ee989d8072fb2b453cf6b9f source 3c6f95dd327ee0730e90f90b56b5a3dd2a2291fb source a30e2862c2bf4635c53a627659905de29934799b source bf237656f829f64805af18a112dda76b4b986429 source 773f7a5223cb745d31243dfe20246e922cb7ad36 source 5d03464526cf4fbb8b6489124c7f7a1a7def4a9f source cdcebac3b5be695bcf390bda116f5a52209c0dd1 source 2f3c3b8a205495df74e809f4167aa51400e5af89 source b0090023b09cdbbfff5cc5a6acf1cc976eb33175 source 0b85a66cc3d8e54747506089f92e154dc7665bfe source 78fb8fe0c5a58bc4d5074de66e77c20c3a441fd3 So it's a range of commits, but the top one db4c4676b70bb5f9a1c169735e8fbe92b097a57b is actually about moving Windows dark mode support out of experimental. In bug 118320 we can see the history. The first effort was already in 7.4 with a3f400886768bf95fbd8e6b236e11d7aac393b96 Related: tdf#118320 enable some windows dark theme support but I guess you need to go to Tools - Options - LibreOffice - Advanced and activate experimental features. I may test this later. Let's call this implementation error for now.
That's a great tip, thanks. I enabled the experimental features and unfortunately the issue is present on the oldest 7.5 commit. I will check older versions.
I bisected 7.4, but the Dark mode seems to have been lagging behind even in bd5daa1c7ee97bfc0ea40abb84858dc78ec7d3c3 where it seems to have been introduced in the experimental features.
(In reply to dolezvo1 from comment #13) > I bisected 7.4, but the Dark mode seems to have been lagging behind even in > bd5daa1c7ee97bfc0ea40abb84858dc78ec7d3c3 where it seems to have been > introduced in the experimental features. Ok, then implementation error is fitting. In the future, please give the source hashes for convenience. In this case it's a3f400886768bf95fbd8e6b236e11d7aac393b96 so indeed the first dark mode commit. To quickly check such suspicions, you may say git log --all --grep=a3f400886768bf95fbd8e6b236e11d7aac393b96 and that would have shown you the binary commit bd5daa1c7ee97bfc0ea40abb84858dc78ec7d3c3 which you could have then checked out. This is mentioned in https://wiki.documentfoundation.org/QA/Bibisect#Checking_out_a_specific_commit_based_on_source_hash
Ah, I see. Sorry, I didn't fully realize how the hashes work.
I can't repro, maybe some dialog specific to test. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f27d2d76c4e577c7231ae755548a8fc20711ca48 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Maybe Skya issue? They are a bit slower without Skya Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f27d2d76c4e577c7231ae755548a8fc20711ca48 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: default; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
I test it using the Define Bibliography Entry Dialog in Writer (Insert > Table of Contents and Index > Bibliography Entry > Document Content > New). Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: f27d2d76c4e577c7231ae755548a8fc20711ca48 CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win Locale: cs-CZ (cs_CZ); UI: en-GB Calc: threaded
Seems it is a special dialog, plenty of fields. What I found is that the scroll, with the wheel, use a different scale of steps than defined in the system.
I am able to replicate it with the "Print" dialog and the "Extensions" manager as well, so it's definitely not just this one dialog. Still wouldn't explain why it only happens in Dark mode and not in Light mode (the scroll step is kind of weird, but it is the exact same in both).
(In reply to dolezvo1 from comment #17) > I test it using the Define Bibliography Entry Dialog in Writer (Insert > > Table of Contents and Index > Bibliography Entry > Document Content > New). Yes, confirmed by comparing dragging of scrollbar in light and dark mode. On Linux with kf6 I don't see any slowness in dark mode. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a366cd34a85a21210939482d229d6d2dd9c1087c CPU threads: 2; OS: Windows 11 X86_64 (build 22621); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded