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
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.
This is LibreOffice issue how?
(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.
(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
(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.
(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.
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.
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.
NEW per confirmations.
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.
(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.
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
Created attachment 136878 [details] samplefile for scrolling sheet
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+.
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.
Resetting earliest per comment 8 perhaps Xisco's new 3.3->5.4 osX bibisect repository will expose the issue. Xisco?
(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...
(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.
(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
Xisco, check out my comment #7 which gives the version where I found the bug to first appear.
Correction: My comment #8 - not 7
> 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.
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.
@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
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.
*** Bug 114579 has been marked as a duplicate of this bug. ***
Same issue seems to occur in other dialogs. For example when scrolling through the list in Tools -> Customize
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
Adding CC to Caolán McNamara
You're absolutely sure that before f7d2bf216afa10268e6a7c1d4613a2fd8f7c7f3c it works and right after f7d2bf216afa10268e6a7c1d4613a2fd8f7c7f3c it doesn't ?
(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...
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
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 ?
(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.
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.
re "wider problem", I don't think so. backports to earlier versions in gerrit now
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.
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.
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.
*** Bug 115395 has been marked as a duplicate of this bug. ***