Created attachment 186419 [details] zip file with 2 small sheet documents to show the problem When in a sheet document rows are fixed Calc doesn't correctly scoll by the mouse wheel. Correctly would be a jump width w = +m or w = -m where the value m is specified in the Windows Mouse settings (how many lines should be moved downwards or upwards when mouse wheel is turned by one "step"). Until LO 7.5.2 (and LOdev 7.5.3) this works correctly, tested last with Version: 7.5.3.0.0+ (X86_64) / LibreOffice Community Build ID: 521ba951d3b983b58f7772fe62d19b07efa19881 CPU threads: 4; OS: Windows 10.0 Build 22624; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded In LOdev 7.6 the jump width "w" is influenced by the number of fixed rows (f) additionally: - Scroll upwards (to the top of the list): w = - m -f - Scroll downwards (to the bottom of the list): w = m - f When m - f < 0 at scrolling downwards Calc scrolls upwards in small steps instead downwards. A special case at scrolling downwards is when m - f = 0. In this case the jump width is alternating 0 and m. To show the bug I have added a zip file with 2 small sheet documents: - Mouse_wheel_scroll_error_Steps.ods: several Jump width values depending on Windows mouse value and the number of fixed rows in a sheet - Scroll-Test_altix_Nummern_V2.ods: document to show the behavior when the mouse wheel is turned at once more than one step When the mouse wheel is turned at once quickly enough more than one step one can scroll downwards also when m - f < 0 but slower as expected and one can see that rows move up and down: - set scroll width in Windows to 3 Lines - open "Scroll-Test_altix_Nummern_V2.ods" from the attached zip file - jump to "-> Ende" (Link in cell D3) on one of the both sheets - try to scroll downwards by turning the mouse wheel Behavior reproduced with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 96aad0d0497c8486f8affc8fed79e63a060c9a59 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded
Reproducible with Scroll-Test_altix_Nummern_V2.ods Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: c4a58634753a84b09f20f7271d6525a6656522d3 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo
I have tried by Git/bisect to find the commit causing the bug but I didn't succeed to reproduce the behavior with the builds created by git: Also with the most new ("Master") the behavior was still OK. Therefore I have looked for the first build the bug can be reproduced with. It is the build with the BuildId 676602a1a4e53e88d9f4664579497d534f6ae9c2 (published 2023-03-23). With the previous build (BuildId b5c3a7502f7ff6ccf0f829c1f3a2ba50b8584c41, published 2023-03-19) the behavior was still OK.
Can it be the repository Win64-7.6 for bisect is updated not often enough? I have cloned this repository - and also tried to update - but soffice built by Git with "master" is to old to reproduce the bug. Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5c78600292d965af157967343a1a4559a086d39a CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-US Calc: CL threaded commit 5c78600292d965af157967343a1a4559a086d39a: Thu Mar 16 16:18:10 2023 +0100 To reproduce the bug a commit at least from March 19 to 23 is necessary.
@Xisco (In reply to Stefan_Lange_KA@T-Online.de from comment #3) > Can it be the repository Win64-7.6 for bisect is updated not often enough?
(In reply to Telesto from comment #4) > @Xisco > (In reply to Stefan_Lange_KA@T-Online.de from comment #3) > > Can it be the repository Win64-7.6 for bisect is updated not often enough? updated
(In reply to Xisco Faulí from comment #5) > (In reply to Telesto from comment #4) > > @Xisco > > (In reply to Stefan_Lange_KA@T-Online.de from comment #3) > > > Can it be the repository Win64-7.6 for bisect is updated not often enough? > > updated Many thanks! I have updated my cloned data and started a new bisect test. Result: I still cannot reproduce the the buggy behavior with the latest build (master)! But I have checked the information given to the BuildId 8bec0ff56c53e80be81a9f463fd1fd21ade33151 and I have seen there is a new commit (today, Fri Apr 07 2023 10:13:29) from Caolán McNamara to fix tdf#154679 "unable to scroll with mouse wheel with frozen rows". The behavior described in tdf#154679 largely corresponds to that I have described in bug 154572. Therefore I think bug 154572 is a duplicate (or a general description) of the behavior described in tdf#154679 and I will check with the next coming build of LOdev7.6 if bug 154572 is resolved too.
I have tested with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 197fc56a624714f284e3d9cb073589d79ce56ed0 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded and the test was really OK: The behavior described in the bug didn't occur. I assume that it was really fixed with commit 8bec0ff56c53e80be81a9f463fd1fd21ade33151 (= fix for Bug 154679), because I could still reproduce the bug with Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 375f85f8518f49ce4381b6663f1e94fc02bacf93 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded What is to do? I would set Bug 154572 to Resolved / Duplicate of Bug 154679.
(In reply to Stefan_Lange_KA@T-Online.de from comment #7) > What is to do? > I would set Bug 154572 to Resolved / Duplicate of Bug 154679. The right course of action, please go ahead with marking your bug as duplicate
as written in comments 6 and 7 *** This bug has been marked as a duplicate of bug 154679 ***