Bug 158842 - 2-finger swipping up/down inverses direction: scrolling vertical becomes horizontal when scrolling up beyond row 1
Summary: 2-finger swipping up/down inverses direction: scrolling vertical becomes hori...
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
24.8.0.0 alpha0+
Hardware: All macOS (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Scrolling-PageUpDown
  Show dependency treegraph
 
Reported: 2023-12-23 16:52 UTC by Telesto
Modified: 2024-04-11 20:16 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Trackpad setting to swipe between pages with 3 finger swipe (768.83 KB, image/png)
2023-12-24 16:04 UTC, Patrick (volunteer)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2023-12-23 16:52:08 UTC
Description:
2-finger swipping up/down inverses direction: scrolling horizontal scrolling when hitting row 1

Same happens swiping left/right. Hitting row will convert scroll to vertical

Steps to Reproduce:
1. Open calc
2. Swipe little down and forcefully up.. scrolls horizontal. From column A to AE in no time
3. Try to scroll back to column A horizontally with some force.. I'm at row 300 in no time

Actual Results:
Scroll doesn't stop at row 1 or column A, but inverses direction

Expected Results:
Stops at A1


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 90b12c9bad55e8f50b75a6d7b68caa27d82cc2b9
CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded
Comment 1 Patrick (volunteer) 2023-12-24 16:04:53 UTC
Created attachment 191588 [details]
Trackpad setting to swipe between pages with 3 finger swipe
Comment 2 Patrick (volunteer) 2023-12-24 16:09:37 UTC
I cannot reproduce this in my local Mac Silicon build:

Version: 24.8.0.0.alpha0+ (AARCH64) / LibreOffice Community
Build ID: 2d514b422257ccf2b53215ee948dda2c9a476d37
CPU threads: 8; OS: macOS 14.2.1; UI render: Skia/Metal; VCL: osx
Locale: en-CA (en_CA.UTF-8); UI: en-US
Calc: threaded

So, two questions for you:

1. Does this behavior occur in an older nightly master build or LibreOffice 24.2 Beta1? Maybe my following hacky patch needs to be reversed?:

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

2. In the System Preferences application's Trackpad > More Gestures tab, what is "Swipe between pages" set to? Normally I set it to "Swipe with two fingers" but when I set it to "Swipe with three fingers" like as shown in the following attachment, I find that my third finger is close enough to the trackpad to cause intermittent page up/down events when a horizontally scroll:

   https://bugs.documentfoundation.org/attachment.cgi?id=191588,
Comment 3 Telesto 2023-12-27 10:54:37 UTC
I have tried a couple of settings.. however doesn't matter
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 40617d867346956588ac023511f31210107217f4
CPU threads: 8; OS: macOS 13.4.1; UI render: Skia/Raster; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded

This issue appears to be hardware specific (or maybe OS version specific, i will  update). I don't encounter the issue in the extend on a older Macbook Air (year 2013, I guess). I can reproduce it, actually, even with LibreOffice 4.4.7.2 or NeoOffice. However it needs much more force, not being a true problem. It happens all the time with my Macbook 2020 Pro
Comment 4 Patrick (volunteer) 2023-12-27 12:38:06 UTC
(In reply to Telesto from comment #3)
> This issue appears to be hardware specific (or maybe OS version specific, i
> will  update). I don't encounter the issue in the extend on a older Macbook
> Air (year 2013, I guess). I can reproduce it, actually, even with
> LibreOffice 4.4.7.2 or NeoOffice. However it needs much more force, not
> being a true problem. It happens all the time with my Macbook 2020 Pro

I have found one case that I can reproduce on my Silicon MacBook Pro. Not sure if it is the same bug, but apparently the following steps confuse the Calc code:

1. Enable 3 finger swipe like in https://bugs.documentfoundation.org/attachment.cgi?id=191588
2. Open a new, empty Calc document
3. Swipe with 2 fingers down around 200 or so rows
4. Swipe with 2 fingers to the right around 100 or more columns
5. Swipe with 3 fingers left and right several times

In step 5, Calc will only move upward regardless of the native 3 finger swipe events.

Also, I vaguely remember this "can only go up" behavior sometimes occurring in NeoOffice (i.e. LibreOffice 4.4) back when I was using an Intel MacBook Pro 2017. Back then, I used fn-up/down arrow keys to page up and down instead of swiping and sometimes fn-down arrow would only go up and I would need to close and reopen the Calc document to stop this behavior.

I will try to see if I can fix the 3 finger swipe bug that I see as I am convinced it is a bug in the Calc code like tdf#152406. Maybe fixing the 3 finger swipe bug will have an effect on the bug that you see.
Comment 5 Telesto 2024-01-23 21:27:31 UTC
It's better now, not 100% perfect but workable
Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: ba8f4bff6015013013df652efbfaf4d9ae10c881
CPU threads: 8; OS: macOS 13.6.3; UI render: Skia/Metal; VCL: osx
Locale: nl-NL (nl_NL.UTF-8); UI: en-US
Calc: threaded
Comment 6 Armondo Lopez 2024-04-11 19:43:07 UTC
I'm 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

or

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 7 Telesto 2024-04-11 20:16:26 UTC
Setting to WFM based on comment 5