Created attachment 184027 [details]
scrollbar has wrong position resulting in stuck document

I'm unable reproduce this issue on my intel Macbook Pro running Monterey. In the sentence that I'm able to reach A1. However they the scrolling/swiping is not natural. I sometimes need to swipe 3 times to get to A1. 

I observe this
1. Open new Calc document
2. Type AAA into cell A1
3. Swipe up (result: Scrolling horizontally; expected: no change)
4. swipe left (result: scrolling vertically; expected: no change)

So hitting the top or the outer left, causes the scroll direction to change..

(In reply to steve from comment #0)


Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 7cda0032806c214ecb998df3a777fd10403fd246
CPU threads: 4; OS: Mac OS X 13.0.1; UI render: Skia/Metal; VCL: osx
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
1.	Open blank calc document. Done.
2.	Issue: scrollbar is stuck at the top most (y) or left most (x) position despite the document not been on the first row or first column.
ML: Did not observe this. The screen shot was useful, but recreating, as per the screenshot, and then moving the vertical scroll bar, and then the horizontal scroll bar, it did not lock up for me. 

3.	Once this happens scrolling in the axis showing the wrong scrollbar position is locked e.g. when y scrollbar is affected document can no longer be scrolled to top. LibreOffice seems to assume the scrollbar position (at the very top) to be correct (it actually is not, since the document is not scrolled to the top).
ML: Did not observe this.

4.	This issue can be worked around by scrolling up and down (or sideways) for a while into the sidebar snaps into correct position which then results in a correctly scrollable document again.


5.	The issue can affect both horizontal and verital scrollbar. I have not observed both scrollbars misbehaving at the same time, although both are affected by this issue and  have misbehaved in described way.


6.	The issue can affect both horizontal and verital scrollbar. I have not observed both scrollbars misbehaving at the same time, although both are affected by this issue and  have misbehaved in described way.


CONCLUSION: I was not able to confirm this behavior.

Adding: The document I am (still) seeing this problem with uses a fixed row (row #1). Maybe this is a factor when trying to reproduce?

@Steve
Do you reproduce this comment 2. And if so, do you think it could be the same (or should a file a different report)

Can others try this: create a few sheets, scroll down in the sheets switch between sheets.

Does that help reproducing the scrollbars getting stuck? For me it is trivial to reproduce (may have to play a minute or so, but so far I have not had a test where the problem does not happen).

(In reply to steve from comment #6)
> Can others try this: create a few sheets, scroll down in the sheets switch
> between sheets.
> 
> Does that help reproducing the scrollbars getting stuck? For me it is
> trivial to reproduce (may have to play a minute or so, but so far I have not
> had a test where the problem does not happen).

Not reproduced on macOS 13 with a fresh master build.

buovjaga: which mouse hardware did you use? Wondering if this maybe only is reproducible with a macOS trackpad.

(In reply to steve from comment #8)
> buovjaga: which mouse hardware did you use? Wondering if this maybe only is
> reproducible with a macOS trackpad.

Virtual

@Alex
Would you mind to test comment 0 and comment 2.

Reproduced on 

Version: 7.6.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 7f23dae00fedc9d7119b44b6c44d9eca4f8c87b8
CPU threads: 8; OS: Mac OS X 13.0.1; UI render: Skia/Metal; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded


daily build 24/01/2023

It takes a lot of scrolling around with the trackpad, but I can reproduce this, especially when scrolling down and across.

For example, I managed to scroll right with the trackpad to column ICG, and down to row 1243.

Further attempts to scroll down result in no new display of the cells moving, but the horizontal scroll bar moves leftwards slowly in increments for no apparent reason, and then after a while, the display suddenly is refreshed by a jump to the left, now displaying ATI in the first visible column.

Something very strange going on.

Maybe linked to some combination of lazy redraw of the display and delayed update of the true position of the scrollbar.

Some kind of scheduling issue ?

FOr me on macOS 13.2.1:

Reproducible with both disabled and enabled skia options:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 5f20f4ff21f597e55d899f5ea4dfe1c1fa5824bc
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

Not Reproducible with both disabled and enabled skia options:

Version: 7.5.0.0.alpha1 (X86_64) / LibreOffice Community
Build ID: 2b4d136b65bc79a1248876160e85fab79d52d5d6
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

Not Reproducible with both disabled and enabled skia options:

Version: 7.4.6.2 / LibreOffice Community
Build ID: 5b1f5509c2decdade7fda905e3e1429a67acd63d
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: en-US
Calc: threaded

With the help of stragu managed to do the bibisect. Hope the macOS wiki (https://wiki.documentfoundation.org/QA/Bibisect/macOS) can be streamlined a bit.

cc:ing Caolán.
 1be0e39deb035c38b42174af661b5ad43d540193 is the first bad commit
commit 1be0e39deb035c38b42174af661b5ad43d540193
Author: libreoffice <libreoffice@libreoffices-MacBook-Air.local>
Date:   Mon Aug 8 20:17:28 2022 +0200

    source 7b20a1b0736825c9c934288428e6e581f79971e2
    
    source 7b20a1b0736825c9c934288428e6e581f79971e2

 LibreOffice.app/Contents/Frameworks/libsclo.dylib  | Bin 18945616 -> 18946480 bytes
 LibreOffice.app/Contents/Frameworks/libsvtlo.dylib | Bin 2585200 -> 2585352 bytes
 LibreOffice.app/Contents/Frameworks/libswlo.dylib  | Bin 19389592 -> 19389680 bytes
 .../Contents/Resources/config/images_breeze.zip    | Bin 1941328 -> 1941328 bytes
 .../Resources/config/images_breeze_dark.zip        | Bin 1937944 -> 1937944 bytes
 .../Resources/config/images_breeze_dark_svg.zip    | Bin 1604710 -> 1604710 bytes
 .../Resources/config/images_breeze_svg.zip         | Bin 1602294 -> 1602294 bytes
 .../Contents/Resources/config/images_colibre.zip   | Bin 2838555 -> 2838555 bytes
 .../Resources/config/images_colibre_dark.zip       | Bin 2738601 -> 2738601 bytes
 .../Resources/config/images_colibre_dark_svg.zip   | Bin 2991776 -> 2991776 bytes
 .../Resources/config/images_colibre_svg.zip        | Bin 3186608 -> 3186608 bytes
 .../Resources/config/images_elementary.zip         | Bin 4255361 -> 4255361 bytes
 .../Resources/config/images_elementary_svg.zip     | Bin 5553404 -> 5553404 bytes
 .../Resources/config/images_karasa_jaga.zip        | Bin 4927261 -> 4927261 bytes
 .../Resources/config/images_karasa_jaga_svg.zip    | Bin 19378231 -> 19378231 bytes
 .../Contents/Resources/config/images_sifr.zip      | Bin 2154225 -> 2154225 bytes
 .../Contents/Resources/config/images_sifr_dark.zip | Bin 2158644 -> 2158644 bytes
 .../Resources/config/images_sifr_dark_svg.zip      | Bin 1799394 -> 1799394 bytes
 .../Contents/Resources/config/images_sifr_svg.zip  | Bin 1795440 -> 1795440 bytes
 .../Contents/Resources/config/images_sukapura.zip  | Bin 3062402 -> 3062402 bytes
 .../Resources/config/images_sukapura_svg.zip       | Bin 4393601 -> 4393601 bytes
 .../Contents/Resources/gallery/sounds.sdg          | Bin 4491 -> 4491 bytes
 LibreOffice.app/Contents/Resources/setuprc         |   2 +-
 LibreOffice.app/Contents/Resources/versionrc       |   2 +-
 24 files changed, 2 insertions(+), 2 deletions(-)

physical mouse or touchpad? Scrolling by clicking on scrollbar and dragging it?

Or is it scrolling by up/down page up/page down and scrollbar not matching position?

I presume calc only and not in writer, etc, right?

If its in the wrong position, and you switch to another sheet and switch back, is it still in the wrong position or does that "fix it"?

When its in the wrong position and you click on the thumb of the scrollbar, does it highlight that thumb in the same "wrong position" (i'm trying to get a hint if its wrongly positioned or not getting redrawn)

(In reply to Caolán McNamara from comment #17)
Thanks for the quick response.

> physical mouse or touchpad? Scrolling by clicking on scrollbar and dragging
> it?

Touchpad (both internal and external aka Apple Magic Trackpad)

> Or is it scrolling by up/down page up/page down and scrollbar not matching
> position?

Touchpad only tested.

> I presume calc only and not in writer, etc, right?

Only observed in calc but I am not using writer a lot so I cannot say with certainty that the behavior is limited to calc.

> If its in the wrong position, and you switch to another sheet and switch
> back, is it still in the wrong position or does that "fix it"?

When switching to another sheet and back the scrollbar is in the correct position, however the scrolling issue was persisting even then. Note that this is not true for 100 % of attempts, since also sometimes it switched back to working state. Note that scrolling can also recover when continuing to scroll around on the hanging spreadsheet (without switching sheets, that is). To me it is still unclear when the hang or recover happens and what triggers it.

> When its in the wrong position and you click on the thumb of the scrollbar,
> does it highlight that thumb in the same "wrong position" (i'm trying to get
> a hint if its wrongly positioned or not getting redrawn)

Not quite sure what you mean with "thumb of the scrollbar".

> When its in the wrong position and you click on the thumb of the scrollbar,
> does it highlight that thumb in the same "wrong position" (i'm trying to get
> a hint if its wrongly positioned or not getting redrawn)

Clicking on the movable scrollbar part does not resolve this. The position remains and the document stays unscrollable.

(In reply to steve from comment #19)
> > When its in the wrong position and you click on the thumb of the scrollbar,
> > does it highlight that thumb in the same "wrong position" (i'm trying to get
> > a hint if its wrongly positioned or not getting redrawn)

I observe this
1. Open new Calc document
2. Type AAA into cell A1
3. Swipe couple of rows down
4. Swipe up again

Result: 
Swiping up (so vertically) row by row is fine, except if keep swiping up as if you could scroll beyond A1 (as if there where a negative reach A -1 A-2) the scroll gets converted to a horizontal scroll right. 

Same happens scrolling horizontally. If scroll beyond A1 to the imaginary negative reach -A1 -B1 you start scrolling down (whereas the swip is going left)

So the swip exceeding the spreadsheet gets converted instead of ignoring swips because end of scrolling range.

Scrolling by pressing left mouse and dragging the scrollbar is working as expected.

"Clicking on the movable scrollbar part does not resolve this. The position remains and the document stays unscrollable." which suggests that its not a paint problem where the scrollbar appears to be in the wrong position, but that its actually is in the wrong position.

For what its worth I see none of this which makes it tricky to do anything about it. My mac only has an external mouse and no trackpad so perhaps the issue is specific to a trackpad scroll variant type.

(In reply to Caolán McNamara from comment #21)
> perhaps the issue is specific to a trackpad scroll variant type.

Might be: need to attach a regular mouse to check.

FWIW there is some specific code around swiping here:
https://opengrok.libreoffice.org/xref/core/vcl/osx/salframeview.mm?r=57b88be1#969

-------
You changed VclPtr<ScrollBar> to VclPtr<ScrollAdaptor in commit 7b20a1b0736825c9c934288428e6e581f79971e2 
'ScrollBar' is mentioned at https://opengrok.libreoffice.org/xref/core/vcl/osx/a11ywrapperscrollarea.mm?r=de1d75a0#42

However, no clue if this being truly related or me making some arbitrary connection...

> For what its worth I see none of this which makes it tricky to do anything about it. My mac only has an external mouse and no trackpad so perhaps the issue is specific to a trackpad scroll variant type.

This matches what Buovjaga reported in https://bugs.documentfoundation.org/show_bug.cgi?id=152406#c9 so might be limited to trackpad mouse usage.

If remote access is helpful, happy to provide that.

Raising Importance to high. For me this bug shows whenever working with Calc. The document becomes unscrollable and I have to use arrow keys to get to the location I want to navigate to.

Steve bibisected to a commit that first made it into 7.5.0.0 alpha, whereas Telesto confirmed for 7.0.0.3.

Telesto, I think you are describing the issue you already reported in bug 135478.

Let's focus here on what Steve describes.

Steve said in the chat he would test with a scrollwheel to see if it makes a difference.

I can now reproduce this bug on my MacBook Pro Silicon running macOS Monterey. Maybe I am doing it wrong, but if I vertically swipe repeatedly, the position will get stuck at a few thousand rows down.

So after the bibsected commit, commit 873a695b64269a6b92766f65930786314351e83f added back the ScTabView::EndScrollHdlUpdate() handler in sc/source/ui/view/tabview.cxx so that UpdateScrollBars() would be called on a mouse release event.

My theory is that UpdateScrollBars() was getting called before the bibisected commit and commit 873a695b64269a6b92766f65930786314351e83f only restore that call for mouse dragging the scrollbar. I put a debug printf in ScTabView::EndScrollHdlUpdate() and it is never called when swiping on the trackpad.

I tried to revert the two patches, but gave up when the old include/vcl/scrbar.hxx and related files. But I think the following change in sc/source/ui/view/tabview.cxx might be a clue:

-    rScrollBar.SetEndScrollHdl( LINK(this, ScTabView, EndScrollHdl) );
+    rScrollBar.SetMouseReleaseHdl(LINK(this, ScTabView, EndScrollHdl));

Maybe I am wrong, but it seems that rScrollBar.SetEndScrollHdl() was removed and replaced with the more narrow rScrollBar.SetMouseReleaseHdl().

Thanks for looking into this, Patrick. This sounds like you have a valid theory as to what is causing the scrollbar issue.

My attempts to reproduce this on an iMac with scrollwheel mmouse failed. I could not reproduce, so issue seems limited to trackpad, which would match buovjaga being unable to reproduce and other feedback.

(In reply to steve from comment #27)
> Thanks for looking into this, Patrick. This sounds like you have a valid
> theory as to what is causing the scrollbar issue.
> 
> My attempts to reproduce this on an iMac with scrollwheel mmouse failed. I
> could not reproduce, so issue seems limited to trackpad, which would match
> buovjaga being unable to reproduce and other feedback.

Unfortunately, I am clueless working in the Calc code (@Caolán McNamara is much more familiar with that code than me). But, I am familiar with the low level code that handles the native swipe events before they are dispatched to Writer, Calc, etc.

So I'll starting debugging from that end and see if I can find if swipe events are being missed or not dispatched to Calc. Hopefully one of us will find the cause somewhere in the middle.

Update: I built the libreoffice-7-5 branch and I can't reproduce this bug even though that branch has the same changes as the master branch. This makes me doubt my original theory. The ScTabView::EndScrollHdlUpdate() handler (both before and after the bibisected commit) only ever called UpdateScrollBars() if a mouse was pressed so there likely is another path which swiping events trigger.

I think I need to find which code actually updates the scrollbar when swiping. Is it a timer? Is there a certain attribute expected in the native swipe event? Hopefully I have some answers to these questions in the next few days.

FWIW. Some pointers. Setting the scroll factor from 1.5 to 1.0 in https://opengrok.libreoffice.org/xref/core/vcl/osx/salframeview.mm?r=57b88be1#43
appears to solve the problem in case of swiping (didn't check with mouse with scroll wheel)

The "-(void)scrollWheel: (NSEvent*)pEvent" code appears to be actually used when swiping. So this https://opengrok.libreoffice.org/xref/core/vcl/osx/salframeview.mm?r=57b88be1#1028

The apparently dedicated code for swipe events "- (void)swipeWithEvent: (NSEvent*)pEvent"  which is more or less a copy of "-(void)scrollWheel: (NSEvent*)pEvent" 
https://opengrok.libreoffice.org/xref/core/vcl/osx/salframeview.mm?r=57b88be1#969
does nothing. I commented out that part, but I don't notice any difference at all

I have a new theory: I put a printf in -[SalFrameView scrollWheel:] and when I encounter the stuck scrollbar bug, I noticed that there was no output from my printf. In other words, -[SalFrameView scrollWheel:] stops getting called when the bug occurs.

This makes me think that LibreOffice is doing some long-running job which is blocking the main thread. My theory is that only when this job is done, does LibreOffice dispatch all of the native swipe events that have been queued by macOS.

@Telesto: the next time you encounter this bug, would you be willing to try to get a sample of the LibreOffice process from the Activity Monitor application? I am hoping that the sample will show us what LibreOffice is doing when the bug occurs. I'll try to grab a sample as well, but for me the bug only occurs for a few seconds so I have had no luck yet.

Spin dump + process sample sent to patrick via dm.
Caolán if you are interested in that information just let me know.

For gtk back in the day I recall we struggled with "smooth scrolling" events with https://bugzilla.redhat.com/show_bug.cgi?id=1367846#c18 and ended up overwhelmed by scroll events. I wonder if trying the same pattern as the gtk3 "AsyncScroll" in vcl/unx/gtk3/gtkframe.cxx would be useful. Launch an Idle on the first scroll event, accumulate the scrolls events and merge together and and dispatch as one scroll notification when the Idle gets fired.

(In reply to Caolán McNamara from comment #35)
> For gtk back in the day I recall we struggled with "smooth scrolling" events
> with https://bugzilla.redhat.com/show_bug.cgi?id=1367846#c18 and ended up
> overwhelmed by scroll events. I wonder if trying the same pattern as the
> gtk3 "AsyncScroll" in vcl/unx/gtk3/gtkframe.cxx would be useful. Launch an
> Idle on the first scroll event, accumulate the scrolls events and merge
> together and and dispatch as one scroll notification when the Idle gets
> fired.

Thanks for the hint! In my testing, macOS isn't getting flooded as the code in vcl/osx/salframeview.mm is pulling all the pending mouse wheel events in the native queue, coalescing them, and then dispatching the combined change.

What is interesting is that the bug becomes easier to reproduce on my MacBook Pro Silicon if I ignore any mouse wheel events that have zero X and Y change (i.e. dispatch less events).

But I think I am getting closer. I can now reproduce this bug if I swipe rapidly and repeatedly from right to left for at least 10 seconds. Then I swipe rapidly, the vertical scrollbar and visible rows stop changing, and the horizontal scrollbar's thumb gets shorter and shifts to the right (i.e. more visible columns are added). Also, if I multiple the X and Y by 10K, I can reproduce the bug using Shift-scrollwheel instead of swiping. In other words, it seems you have to jump way out right (maybe past 8K columns?) very rapidly to trigger this bug. 

Theory: Calc is repeatedly running an idle timer that expands the number of visible columns in the sheet (i.e. a horizontal scroll wheel handler). What is interesting is that after this idle timer adds all columns, all vertical scroll wheel events dispatched in vcl are ignored. Other mouse events and key events are handled normally (even dragged the scrollbar thumb) so my last theory that a long-running job was blocking the main thread was wrong.

So I think Calc's idle timer that adds visible columns blocks handling of vertical scroll wheel events until an unknown condition is set. So far, another horizontal scroll wheel event is the only known case that will set this unknown condition. Even adding the maximum 16K columns does not seem to set this condition.

@Telesto: thank you for the samples. One sample is repainting the scrollbar in a timer and that helped me come up with my current theory.

(In reply to Patrick Luby from comment #36)
> Also, if I multiple the X and Y by 10K, I
> can reproduce the bug using Shift-scrollwheel instead of swiping. In other
> words, it seems you have to jump way out right (maybe past 8K columns?) very
> rapidly to trigger this bug.

Here's a diff that you can use to reproduce the bug by spinning the scroll wheel while pressing the Shift key. Open an empty spreadsheet, Shift-scrollwheel 5 to 10 times, then release the Shift key and scrollwheel:

diff --git a/vcl/osx/salframeview.mm b/vcl/osx/salframeview.mm
index ae9528306cfa..c22812b6c894 100644
--- a/vcl/osx/salframeview.mm
+++ b/vcl/osx/salframeview.mm
@@ -1048,6 +1048,10 @@ -(void)scrollWheel: (NSEvent*)pEvent
             pEvent = pNextEvent;
         }
 
+        dX *= 100000;
+        dY *= 100000;
+
+
         NSPoint aPt = [NSEvent mouseLocation];
         mpFrame->CocoaToVCL( aPt );
 
Note: I found two other cases where you can escape from this bug so here is the complete list:
- Horizontal scrollwheel
- Click anywhere in vertical scrollbar
- Click in native menubar

(In reply to Patrick Luby from comment #37)
> Here's a diff that you can use to reproduce the bug by spinning the scroll
> wheel while pressing the Shift key. Open an empty spreadsheet,
> Shift-scrollwheel 5 to 10 times, then release the Shift key and scrollwheel:

One more data point: with my patch in comment #37, if I swipe horizontally I can get to the column furthest to the right and immediately vertically swipe without any problem.

This makes me think that the idle timer is waiting for the maximum column number to be added to the visible columns and the idle timer is just getting overwhelmed by the number of visible columns to add. Since swiping makes significantly larger jumps than a scroll wheel triggers the bug but making the jump ridiculously high does not, I think that there is some jump range that creates significantly more new visible columns to add and so it just takes forever for the idle timer to plough through adding all those columns. Whereas when you can jump to the end of the columns with a handful of swipes, maybe the idle timer only needs to handle a few hundred visible rows in total?

(In reply to Patrick Luby from comment #38)
This mentions a scroll timer
https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/tabview.cxx?r=0908c7c1#236

(In reply to Telesto from comment #39)
> (In reply to Patrick Luby from comment #38)
> This mentions a scroll timer
> https://opengrok.libreoffice.org/xref/core/sc/source/ui/view/tabview.
> cxx?r=0908c7c1#236

Thank you for the hint. Unfortunately, scroll wheel events never trigger starting that timer. But, I did find that vcl/source/window/winproc.cxx sends all scroll wheel events to Writer, Calc, etc. as a "CommandEventId::Wheel". By grepping that event ID in the source code in the sc directory, I found the Calc handler: ScTabView::ScrollCommand() in the same file as the timer you found.

I'll start walking throught the ScTabView::ScrollCommand() code and post again when I find something.

I think that I have fixed this bug in the following patch:

https://gerrit.libreoffice.org/c/core/+/149183

I tested this patch with a trackpad and (after applying my patch in comment #37) with a scroll wheel and I no longer can reproduce the bug.

Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/d82a734c07b85cbd7861699b7fa6d3ebbb3122f2

tdf#152406 Disable anti-jitter code for scroll wheel events

It will be available in 7.6.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-7-5":

https://git.libreoffice.org/core/commit/12fdd2792c392a5b355110836faa40db5866e57e

tdf#152406 Disable anti-jitter code for scroll wheel events

It will be available in 7.5.3.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.

Fix verified. Not only is the issue with the stuck scrollbars in wrong positions gone but scrolling overall is more responsive.

Thanks so much Patrick for spending the time and effort to get to the bottom of this and even providing a patch.

Can't stress enough, how nice it is to be able to use calc again 😅

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1cfeb4bd8ce7f7727a81136bd3e2d6ebea976895
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Metal; VCL: osx
Locale: de-DE (en_DE.UTF-8); UI: en-US
Calc: threaded

Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-7-5-2":

https://git.libreoffice.org/core/commit/ea0e721246222c3d470c07d429137f0634592833

tdf#152406 Disable anti-jitter code for scroll wheel events

It will be available in 7.5.2.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.