Bug 109062 - Scrolling with touchpad or scrollwheel is not working on Mac
Summary: Scrolling with touchpad or scrollwheel is not working on Mac
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.3.4.1 rc
Hardware: Other Mac OS X (All)
: medium normal
Assignee: Caolán McNamara
URL:
Whiteboard: target:6.1.0 target:5.4.5 target:6.0.1
Keywords: bisected, regression
: 114579 115395 (view as bug list)
Depends on:
Blocks: MacOS-Wishlist
  Show dependency treegraph
 
Reported: 2017-07-11 09:37 UTC by Markus Vogt
Modified: 2018-02-02 11:18 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
samplefile for scrolling sheet (87.82 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-10-09 18:04 UTC, V Stuart Foote
Details
Patch proposal (868 bytes, text/plain)
2018-01-19 17:04 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Vogt 2017-07-11 09:37:14 UTC
Description:
The 2 finger scroll down function on the touch pad isn't working propperly. 

Actual Results:  
Close and reopen

Expected Results:
Still not functional propperly.


Reproducible: Always

User Profile Reset: 

Additional Info:


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:54.0) Gecko/20100101 Firefox/54.0
Comment 1 Ludovic LANGE 2017-07-11 11:50:27 UTC
I also face the same issue on MacOS Sierra 10.12.5 (16F73) on a MacBookPro13,3.

To add more context, the 2-finger scroll down does not work at default acceleration, nor the 2-finger scroll right.
2-finger scroll is the "Scroll" gesture defined here: https://support.apple.com/en-us/HT204895

(I don't know if "acceleration" is the proper term to explain the difference between a slow-scroll, and a very-fast-then-lift-your-fingers-to-give-inertia type scroll)
To make it work, you need to really give a lot of momentum/inertia to your 2-finger gesture, as if you'd like to increase the acceleration and scroll by an amount of multiple lines / columns.

To reproduce it:

a) LibreOffice -> New Spreadsheet.

b) go (with cursor for example) to a high-column, high-row , e.g. $CA$100

c) with the trackpad, using 2-finger gestures, do:

1) slow, continuous gesture from the bottom of the trackpad to its top (this is the SCROLL DOWN gesture) : nothing happens (UNEXPECTED).

2) slow, continuous gesture from the right of the trackpad to its left (this is the SCROLL RIGHT gesture) : nothing happens (UNEXPECTED).

3) fast, continuous gesture with momentum/inertia, from the bottom of the trackpad to its top (this is the accelerated SCROLL DOWN gesture) : scrolling works towards the bottom of the document, multiple lines by multiple lines (expected).

4) fast, continuous gesture with momentum/inertia, from the right of the trackpad to its left (this is the accelerated SCROLL RIGHT gesture) : scrolling works towards the right of the document, multiple columns by multiple columns (expected).

5) slow, continuous gesture from the left of the trackpad to its right (this is the SCROLL LEFT gesture) : scrolling works towards the left of the document column by column (expected).

6) slow, continuous gesture from the top of the trackpad to its bottom (this is the SCROLL UP gesture) : scrolling works towards the top of the document line by line (expected).


Same scrolling (1 or 2 fingers) with the "Magic Mouse" (v1) works as expected.


I hope this clears the issue faced.
Comment 2 V Stuart Foote 2017-07-11 18:25:31 UTC
This is LibreOffice issue how?
Comment 3 Alex Thurgood 2017-07-13 09:09:18 UTC
(In reply to V Stuart Foote from comment #2)
> This is LibreOffice issue how?

If confirmed (I have yet to test), one might argue that LibreOffice should properly support Apple's scroll gestures.
Comment 4 Alex Thurgood 2017-07-13 09:54:54 UTC
(In reply to Ludovic LANGE from comment #1)

> To reproduce it:
> 
> a) LibreOffice -> New Spreadsheet.
> 
> b) go (with cursor for example) to a high-column, high-row , e.g. $CA$100
> 
> c) with the trackpad, using 2-finger gestures, do:
> 
> 1) slow, continuous gesture from the bottom of the trackpad to its top (this
> is the SCROLL DOWN gesture) : nothing happens (UNEXPECTED).


NO REPRO - if I slowly move 2 fingers on my MBPro touchpad from bottom to top, the display adjusts accordingly, moving cells up so that the selected cell CA100 moves out of the displayed range of cells, i.e. effectively scrolling down slowly.



> 
> 2) slow, continuous gesture from the right of the trackpad to its left (this
> is the SCROLL RIGHT gesture) : nothing happens (UNEXPECTED).


NO REPRO - using 2 fingers to move right or left moves the visual position of selected cell CA100 to the left or right as appropriate.


> 
> 3) fast, continuous gesture with momentum/inertia, from the bottom of the
> trackpad to its top (this is the accelerated SCROLL DOWN gesture) :
> scrolling works towards the bottom of the document, multiple lines by
> multiple lines (expected).


NO REPRO - depending on inertia given to 2 finger gesture, cell display moves by anything between 100 to approx. 200 rows.


> 
> 4) fast, continuous gesture with momentum/inertia, from the right of the
> trackpad to its left (this is the accelerated SCROLL RIGHT gesture) :
> scrolling works towards the right of the document, multiple columns by
> multiple columns (expected).
> 

NO REPRO - I can reach column A from column CA in a single gesture. I can reach the extreme limit (column AMJ) of the sheet starting from column A in 4 double-finger sweeps.


> 5) slow, continuous gesture from the left of the trackpad to its right (this
> is the SCROLL LEFT gesture) : scrolling works towards the left of the
> document column by column (expected).
> 

WFM




> 6) slow, continuous gesture from the top of the trackpad to its bottom (this
> is the SCROLL UP gesture) : scrolling works towards the top of the document
> line by line (expected).
> 
>


WFM



I can't reproduce any of the buggy behavioural issues you describe.
My tests were carried out on a MBPro 15", end-2013, with OSX Sierra 10.12.5
Comment 5 Alex Thurgood 2017-07-13 09:56:45 UTC
(In reply to Alex Thurgood from comment #4)


> > 
> > 4) fast, continuous gesture with momentum/inertia, from the right of the
> > trackpad to its left (this is the accelerated SCROLL RIGHT gesture) :
> > scrolling works towards the right of the document, multiple columns by
> > multiple columns (expected).
> > 
> 
> NO REPRO - I can reach column A from column CA in a single gesture. I can
> reach the extreme limit (column AMJ) of the sheet starting from column A in
> 4 double-finger sweeps.
> 
> 

And I can move back to column A again in two sweeps.
Comment 6 Markus Vogt 2017-07-13 13:00:41 UTC
(In reply to Alex Thurgood from comment #3)
> (In reply to V Stuart Foote from comment #2)
> > This is LibreOffice issue how?
> 
> If confirmed (I have yet to test), one might argue that LibreOffice should
> properly support Apple's scroll gestures.

Thanks all,
That's the first time this ever occured over all the years I use LibreOffice versions on OS X versions.
Comment 7 Jim Bowen 2017-08-11 13:32:13 UTC
I have the same (or similar) problem with LibreOffice Calc 5.4.0.3 on my MacBook Air (11-inch, Early 2014) running macOS Sierra 10.12.6

The problem occurs when scrolling down or to the right with either a wireless mouse scroll wheel or with a 2-finger drag on the touch pad. The problem occurs with Calc in both .ods and .xlsx formats. The is no problem scrolling in text documents.

Scrolling up or left works normally. Attempting to scroll down or right slowly or by a single cell produces no movement at all. Attempting a faster scroll down or right works but is not controllable, so there is no way to scroll in these directions and control the amount of scroll.

I have previously run Calc with no scrolling problem, but unfortunately I can not be sure whether the issue appeared with a LibreOffice or a macOS update.
Comment 8 Jim Bowen 2017-08-12 11:59:10 UTC
Further to my Comment 7, I have tested numerous older versions. I find that my MacBook Air (11-inch, Early 2014) running macOS Sierra 10.12.6 has no scrolling issues up to and including LibreOffice_5.3.3.2_MacOS_x86-64.dmg. The scrolling issues with Calc that I described in Comment 7 begin with LibreOffice_5.3.4.1_MacOS_x86-64.dmg and continue in all later releases I have tested including the current 5.4.0.3.
Comment 9 Buovjaga 2017-08-14 11:31:26 UTC
NEW per confirmations.
Comment 10 rwhite 2017-10-07 01:41:15 UTC
Confirming this behavior for LibreOffice 5.3.6.1 running on a MacBookAir6,2 with i7 processor running macOS 10.12.6. I have a 139 Kb document with 50 or so rows of multi-line cells, and scrolling down or across--using either two-finger gesture on touchpad or Logitech mouse--is halting, laggy, and inconsistent.

As noted previously, scrolling up or to the left works fine.

On the MacBookAir6,2 I downloaded an old copy of LibreOffice 5.2.7002, and the same 139 Kb document scrolls without issue in any direction, suggesting this is an issue related to LibreOffice versions after 5.2.7 for macOS.
Comment 11 Raymond Wu Won 2017-10-09 16:32:47 UTC
(This comment originally posted under https://bugs.documentfoundation.org/show_bug.cgi?id=109220)

I've just noticed this with Version: 5.4.2.2 (64-bit) on macOS High Sierra 10.13 with 8GB RAM and an SSD (2016 13" MBP). It seemed more noticeable after upgrading from an older release (before 5.3.6).

* It doesn't happen with Writer.
* All other applications closed to test it wasn't them hogging memory.
* Scroll lag occurs on blank Calc sheets (both in safe mode and normal mode, reset of profile also seemed to change nothing).
* OpenGL enabled or disabled seems to make no difference (default is disabled)
* Antialiasing settings seem to make no difference.
* I tweaked the memory settings to double the default and noticed no change.

Scrolling by one or two cells at a time is impossible - there's a delay between dragging on the trackpad and anything from happening; only larger scroll movements work. Limited settings are available for macOS with the trackpad. It's completely unresponsive with a slight drag in two finger scroll mode.

And now, I've just uninstalled it and put 5.3.6.1 on.

Scrolling down seems more unresponsive than scrolling up! In fact, scrolling up now appears possible by one cell at a time. Is it a (blank) cell population thing? CPU utilisation spikes in both directions according to Activity Monitor.

I suppose the workaround right now is to do a big sweeping scroll motion down (or page down), followed by more incremental up scrolling. You really have to scroll at a fast speed to get it to move - dragging the fingers slowly to scroll down will never get it moving.

Also checked my settings to ensure that it had nothing to do with the scroll direction settings (i.e., "natural" swipe to scroll vs conventional move fingers down to scroll).

I notice the same effects if I Cmd+Down to the bottom of the sheet (row 1048576 - hiding most of the rows in the sheet hasn't helped either). Going up seems to present no issue with 5.3.6.1, but down is a struggle.

Additionally, dialog boxes as well as the launcher are sluggish. Cmd+1 for Cell Properties always takes a couple of seconds to respond.
Comment 12 V Stuart Foote 2017-10-09 17:52:44 UTC
This does not affect macOS 10.12.6 on 6,2 Mac mini with 0x030d Apple Magic Mouse. One finger Scroll up/down and swipe left/right scroll are smooth and crisp.

This mouse driver/hardware does not have the two finger/three finger based gestures.

Also, on this macOS 10.12.6 system, a USB two button mouse with Wheel also scrolls vertically smoothly down and up.

Rather suggests implementing this is would require enhancement to implement new macOS hardware features. And at the moment not our bug, similar to request for bug 105803 for Touchbar support that needs dev attention

Version: 6.0.0.0.alpha0+
Build ID: 892c719fffa06de4c7aeab497326cad7bae9e5c6
CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; 
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2017-09-27_02:00:53
Locale: en-US (en_US.UTF-8); Calc: group
Comment 13 V Stuart Foote 2017-10-09 18:04:46 UTC
Created attachment 136878 [details]
samplefile for scrolling sheet
Comment 14 Raymond Wu Won 2017-10-10 19:29:58 UTC
Conversely, my Mac (without a Touch Bar) doesn't seem to offer single finger scroll in the stock options.

I just checked with a USB mouse and the same issue appears to be identical with LibreOffice 5.3.6, 5.3.4 and 5.4.2 in macOS 10.13. Scrolling up on a blank sheet is fine (one detent at a time), but I have to spin the wheel faster through a few detents to go down at all.

Needless to say, it's fine in 5.3.6 for Fedora 26 and earlier versions too on Ubuntu 16.04.

I've gone back to 5.3.3.2 now as per Jim's comment 7 & 8 which works fine. I also can't remember what it was like before High Sierra, but don't recall noticing it so perhaps it's a combination of that along with 5.3.4+.
Comment 15 Igor 2017-12-04 15:53:32 UTC
Hi! 
After 5.2.7.2 LO version have been released, all new version have a next issue with LO Calc:
Scrolling with the touchpad isn't work smoothly with bad response to gestures.

Hardware: Macbook Air 2012 i5 4GB RAM
High Sierra OS X.
Comment 16 V Stuart Foote 2017-12-04 16:42:04 UTC
Resetting earliest per comment 8

perhaps Xisco's new 3.3->5.4 osX bibisect repository will expose the issue.

Xisco?
Comment 17 Xisco Faulí 2017-12-05 10:12:04 UTC
(In reply to V Stuart Foote from comment #16)
> Resetting earliest per comment 8
> 
> perhaps Xisco's new 3.3->5.4 osX bibisect repository will expose the issue.
> 
> Xisco?

Yep, it can be downloaded from https://dev-downloads.libreoffice.org/bibisect/mac/Bibisect_MacOSX10.13_release-lo-3.3.0.4_to_lo-5.4.3.2.bz2

Unfortunately, i don't have a touchpad as I use a mac mini...
Comment 18 Jim Bowen 2017-12-05 12:16:11 UTC
(In reply to Xisco from comment #17)
> Unfortunately, i don't have a touchpad as I use a mac mini...

As I wrote in comment #7 (but easily overlooked in this lengthy thread) I found the problem was exactly the same when attempting to scroll using the scroll wheel on a wireless mouse.
Comment 19 Xisco Faulí 2017-12-05 12:20:33 UTC
(In reply to Jim Bowen from comment #18)
> (In reply to Xisco from comment #17)
> > Unfortunately, i don't have a touchpad as I use a mac mini...
> 
> As I wrote in comment #7 (but easily overlooked in this lengthy thread) I
> found the problem was exactly the same when attempting to scroll using the
> scroll wheel on a wireless mouse.

I don't have a wireless mouse neither.
OTOH, I'd be lovely if you could download the repo I mentioned in comment 17 in order to find in which version the issue was introduced
Comment 20 Jim Bowen 2017-12-05 12:27:33 UTC
Xisco, check out my comment #7 which gives the version where I found the bug to first appear.
Comment 21 Jim Bowen 2017-12-05 12:32:34 UTC
Correction: My comment #8 - not 7
Comment 22 Raymond Wu Won 2017-12-06 08:02:50 UTC
> I don't have a wireless mouse neither.

In Comment 14, I said that I get the same problem with a USB mouse - by that, I meant a wired USB mouse (Zowie EC1-A to be precise; it's a mouse that requires no drivers). Trackpad, wired and wireless mouse makes no difference.
Comment 23 Carsten 2017-12-09 12:10:47 UTC
I can reproduce the erratic scrolling behavior on two MacBooks.

MacBook Air, Mid 2011, High Sierra 10.13.1
MacBook Pro, 2017, High Sierra 10.13.1

On both machines, scrolling works fine up to version 5.3.3.2, the erratic behavior starts with version 5.3.4.1.

The symptoms are as described before: scrolling towards higher rows (down) and columns (right) is not working reliable, sometimes it takes 3 two-finger-touches to start scrolling with the touchpad. Calc is not usable with that behavior.

Independent from this erratic behavior, the scrolling performance on the MacBook Pro is very poor unless I switch the color profile to the standard RGB profile. It doesn't reach the performance of the 6 years-older MacBook Air, where I can't detect an impact of the color profile to the scrolling performance at all.
Comment 24 Telesto 2017-12-09 18:39:09 UTC
@Carsten
(In reply to Carsten from comment #23)
> Independent from this erratic behavior, the scrolling performance on the
> MacBook Pro is very poor unless I switch the color profile to the standard
> RGB profile. It doesn't reach the performance of the 6 years-older MacBook
> Air, where I can't detect an impact of the color profile to the scrolling
> performance at all.

Interesting. Please open a new bug report for this one. Thanks
Comment 25 Telesto 2017-12-09 19:37:39 UTC
I'm able to repro this one. Same specs as comment 7. A likely candidate - based on comment 8 - would be the commit for bug 103158, in my opinion.
Comment 26 Telesto 2017-12-20 16:49:15 UTC
*** Bug 114579 has been marked as a duplicate of this bug. ***
Comment 27 Telesto 2018-01-09 10:23:58 UTC
Same issue seems to occur in other dialogs. For example when scrolling through the list in Tools -> Customize
Comment 28 Telesto 2018-01-17 22:48:02 UTC
Manual bisected to 
author	Caolán McNamara <caolanm@redhat.com>	2017-05-16 10:12:09 +0100
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2017-05-24 10:36:16 +0200
commit	f7d2bf216afa10268e6a7c1d4613a2fd8f7c7f3c (patch)
tree	a7a36402f4d630b4bc9006ba153018a4bf2fa2d9
parent	c05f35f4f56a1e65b92f4b1bc43b0fa6138d209c (diff)
Resolves: tdf#103174 & rhbz#1367846 improve gtk3 trackpad scrolling
convert number of "lines" scrolled to double and allow
fractional parts of lines/columns

Repro with
Version: 5.3.4.0.0+
Build ID: 1a14a0404ef02a76cfc3b6bfd50b1c78bb150d45
CPU Threads: 4; OS Version: Mac OS X 10.13.1; UI Render: default; Layout Engine: new; 
Locale: nl-NL (nl_US.UTF-8); Calc: group

No repro with
Version: 5.3.4.0.0+
Build ID: c05f35f4f56a1e65b92f4b1bc43b0fa6138d209c
CPU Threads: 4; OS Version: Mac OS X 10.13.1; UI Render: default; Layout Engine: new; 
Locale: nl-NL (nl_US.UTF-8); Calc: group

https://opengrok.libreoffice.org/xref/core/vcl/osx/salframeview.mm#833
Comment 29 Telesto 2018-01-17 22:48:55 UTC
Adding CC to Caolán McNamara
Comment 30 Caolán McNamara 2018-01-18 12:05:37 UTC
You're absolutely sure that before f7d2bf216afa10268e6a7c1d4613a2fd8f7c7f3c it works and right after f7d2bf216afa10268e6a7c1d4613a2fd8f7c7f3c it doesn't ?
Comment 31 Telesto 2018-01-18 15:31:38 UTC
(In reply to Caolán McNamara from comment #30)
> You're absolutely sure that before f7d2bf216afa10268e6a7c1d4613a2fd8f7c7f3c
> it works and right after f7d2bf216afa10268e6a7c1d4613a2fd8f7c7f3c it doesn't
> ?

The summary is misleading. Comment 7 has a proper description.  
* "Scrolling up or left works normally. Attempting to scroll down or right slowly or by a single cell produces no movement at all. Attempting a faster scroll down or right works but is not controllable, so there is no way to scroll in these directions and control the amount of scroll." [Comment 7]

* The same issue seems to occur in other dialogs. For example when scrolling through the list in Tools -> Customize

* The is no problem scrolling in text documents. 

It should be the identified commit...
Comment 32 Telesto 2018-01-19 17:04:17 UTC
Created attachment 139219 [details]
Patch proposal

@Caolán
I might found a clue (or a solution). Changing "fabs" to std:abs has the desired effect. For example here: https://opengrok.libreoffice.org/xref/core/vcl/osx/salframeview.mm#941

See also: https://forums.developer.apple.com/thread/90710
Comment 33 Caolán McNamara 2018-01-20 20:06:58 UTC
aha, excellent stuff Telesto, the old situation would have truncated some 0.X cases to 0, which would then have been detected as 0 and the = 1 would happen. Seeing as you appear to be in a position to compile it yourself to test it, does https://gerrit.libreoffice.org/#/c/48249/ solve the problem ?
Comment 34 Telesto 2018-01-21 10:37:16 UTC
(In reply to Caolán McNamara from comment #33)
> aha, excellent stuff Telesto, the old situation would have truncated some
> 0.X cases to 0, which would then have been detected as 0 and the = 1 would
> happen. Seeing as you appear to be in a position to compile it yourself to
> test it, does https://gerrit.libreoffice.org/#/c/48249/ solve the problem ?

Working like a charm! Thanks Caolán! 

Side note: could this be a wider problem? My initial solution for bug 92190 was defining the paper-size into millimeters instead of inches. Weird, but working. (Ignore the 0.5 part)

See comment: https://bugs.documentfoundation.org/show_bug.cgi?id=92190#c76

and response of Tor Lillqvist
https://bugs.documentfoundation.org/show_bug.cgi?id=92190#c82

I came up with a different 'solution', but there might be a problem underneath.
Comment 35 Commit Notification 2018-01-22 10:31:35 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf92a5af6cb2928578bade9d367738d7e0f283e7

tdf#109062 restore osx scrollwheel logic

It will be available in 6.1.0.

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

Affected users are encouraged to test the fix and report feedback.
Comment 36 Caolán McNamara 2018-01-22 10:41:40 UTC
re "wider problem", I don't think so.

backports to earlier versions in gerrit now
Comment 37 Commit Notification 2018-01-25 18:25:53 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=378d7d68d9e842039bcf797a8b95c2e85768e1e7&h=libreoffice-5-4

tdf#109062 restore osx scrollwheel logic

It will be available in 5.4.5.

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

Affected users are encouraged to test the fix and report feedback.
Comment 38 Jim Bowen 2018-01-26 05:35:16 UTC
From brief testing using the trackpad on my Mac Air I find the problem to be resolved in the 25 Jan daily build for 5.4 (Version: 5.4.5.0.0+). The 25 Jan daily build for 6.0 still retains the problem.
Comment 39 Commit Notification 2018-01-29 08:04:03 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fd25b9752a4ba2d0898d261fe6092d5f6ffbde20&h=libreoffice-6-0

tdf#109062 restore osx scrollwheel logic

It will be available in 6.0.1.

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

Affected users are encouraged to test the fix and report feedback.
Comment 40 Telesto 2018-02-02 11:18:14 UTC
*** Bug 115395 has been marked as a duplicate of this bug. ***