Description: The horizontal scrolling direction in all Libreoffice products, when using a two-finger swipe to navigate around a document, is inverted (if I perform a right swipe, the scrollbar moves to the left, and vice versa). The vertical scrolling direction, when performing the up/down swipe, works as expected. All of the other applications which feature horizontal scrolling that I've tested so far (firefox, evince, gimp) exhibit the correct behavior, and I haven't managed to find a setting in Libreoffice which might be able to correct this. My system does not have any kind of "reverse scrolling direction" setting activated. I've also checked that activating this setting does not reverse the horizontal scrolling direction, but just the vertical one, in all applications (including Libreoffice). Note: I don't know if this is related to bug 76017, or if the bug is, as mentioned there, vendor-specific, but unfortunately I don't have another platform to test this on. I am not using Windows nor the Linux Synaptic driver, so I thought that a separate report could be useful. Steps to Reproduce: 1. open any Libreoffice product (calc, writer, etc.) on a laptop 2. use a two-finger swipe gesture from left to right on the touchpad Actual Results: The horizontal scrollbar moves from right to left, the opposite of the swipe gesture Expected Results: The horizontal scrollbar should move from left to right, in the same direction as the swipe gesture Reproducible: Always User Profile Reset: Yes Additional Info: [From the help] Version: 6.3.0.2 Build ID: 1:6.3.0~rc2-1 CPU threads: 8; OS: Linux 4.19; UI render: default; VCL: gtk2; Locale: en-GB (en_GB.UTF-8); UI-Language: en-GB Calc: threaded [System] Distribution: Debian Unstable 4.19.37-6 (2019-07-18) x86_64 GNU/Linux Desktop environment: XFCE 4.12 Input device: elan touchpad on Thinkpad T480s Input device driver: xserver-xorg-input-libinput 0.28.2-2
I am getting the same result with 6.3.x, but on MacOS. I had wondered whether in my case because I'm on MacOS beta it was something from that, but looks like not.
This is the same problem that I described over 5 years ago when I opened Bug 76017. Others have then dragged that bug report in various different directions, and to this day the original bug still has not been fixed. This problem does not appear to be tied to a specific platform or version. I've observed it consistently in all my use of LibreOffice, across all versions of LibreOffice dating at least as far back as 4.x til now (6.x), across multiple laptops of various different manufacturers and models, and across multiple OS versions of both Windows (7, 8, 10) and Linux (CentOS 6, 7).
For MacOS, this only (re)appeared in a recent 6.3 beta. Scrolling is fine on Mac touchpads in 6.2, but that's not to say it is any better on other hardware. Bibisected using bibisect-mac64-6.3 Commit: 845743131b733b52eb913048f55f5efdd013b24f Adding Cc: to Jan-Marek Glogowski
Version: 6.3.0.4 Build ID: 057fc023c990d676a43019934386b85b21a9ee99 CPU threads: 4; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: threaded confirmed, this is now in the stable release and it's highly irritating. Setting to "New" as this is confirmed by various users.
I am able to confirm this bug happens for me also, on MacOS 10.13.6 with LibreOffice 6.3.0, and it does not happen in LibreOffice 6.2.5.2. This bug is a show-stopper, and forced me to downgrade, because it's almost impossible to retrain your fingers to one backwards application on an entire computer full of correct applications.
(In reply to Matthew Hall from comment #5) > I am able to confirm this bug happens for me also, on MacOS 10.13.6 with > LibreOffice 6.3.0, and it does not happen in LibreOffice 6.2.5.2. > > This bug is a show-stopper, and forced me to downgrade, because it's almost > impossible to retrain your fingers to one backwards application on an entire > computer full of correct applications. I've just tested the Flatpak version of LibreOffice (6.2.5.2), and can confirm that the bug is not present there, so until this behavior is fixed, using the Flatpak version may be a viable workaround for users on Linux who don't want to (or aren't able to) downgrade their LibreOffice installation.
With Linux + libinput + GNOME 3.32, all applications including Libreoffice, when I two-finger scroll from left-to-right, the scrollbar moves from right-to-left. The scrollbar moves in the opposite direction. This is the expected behavior. Libreoffice is behaving like every other app. You can test Firefox and Chrome on a page by zooming into: https://tinderbox.libreoffice.org/MASTER/status.html Also tested evince. In all cases both vertical and horizontal 2-finger scrolling is reversed. This seems by design and not a bug. From bug 76017, comment 6 > The expected behavior (standard across all applications and all platforms) is that a two-finger scroll on a touch pad drags the sheet, NOT the scrollbar. Remember that the sheet and the scrollbar move in opposite directions from each other. With a two-finger scroll on a touchpad, the expected behavior is that the sheet moves in the direction of the gesture, which means the scroll bars move in the opposite direction. > This is standard across all applications, and in fact LibreOffice does it correctly in the vertical axis. It's only in the horizontal axis
With Linux + libinput + GNOME 3.32, all applications including Libreoffice, when I two-finger scroll from left-to-right, the scrollbar moves from right-to-left. The scrollbar moves in the opposite direction. This is the expected behavior. Libreoffice is behaving like every other app. You can test Firefox and Chrome on a page by zooming into: https://tinderbox.libreoffice.org/MASTER/status.html Also tested evince. In all cases both vertical and horizontal 2-finger scrolling is reversed. This seems by design and not a bug. From bug 76017, comment 6 > The expected behavior (standard across all applications and all platforms) > is that a two-finger scroll on a touch pad drags the sheet, NOT the scroll > bar. Remember that the sheet and the scroll bar move in opposite directions > from each other. With a two-finger scroll on a touch pad, the expected > behavior is that the sheet moves in the direction of the gesture, which > means the scroll bars move in the opposite direction. > > This is standard across all applications, and in fact LibreOffice does it > correctly in the vertical axis. It's only in the horizontal axis that > LibreOffice has it wrong.
OK, I see the problem, under Steps to Reproduce, you need to add * Settings -> Mouse and Touchpad -> Natural Scrolling -> OFF With natural scrolling disabled, only LibreOffice has reversed horizonal scroll. Vertical scroll is correct. Note: this is not the default setting for Ubuntu or Arch. That's why I had so much trouble reproducing this issue.
To be clear, I can reproduce this issue under Arch + gnome + libinput. It was the instructions that I found confusing.
(In reply to Luke from comment #9) > OK, I see the problem, under Steps to Reproduce, you need to add > > * Settings -> Mouse and Touchpad -> Natural Scrolling -> OFF > > With natural scrolling disabled, only LibreOffice has reversed horizonal > scroll. Vertical scroll is correct. > > > Note: this is not the default setting for Ubuntu or Arch. That's why I had > so much trouble reproducing this issue. I just tried the same on MacOS, and got the same result. Horizontal scroll reversed to other apps, vertical correct.
*** Bug 126817 has been marked as a duplicate of this bug. ***
*** Bug 126854 has been marked as a duplicate of this bug. ***
it can't be a LibreOffice 4.2 problem since the bisection points to a commit from 2019-06-14
I intentionally broke this, to be reminded to fix all the non-qt5 based backends. In the end I didn't find the time and actually forgot about it. Gerrit revert for master: https://gerrit.libreoffice.org/#/c/77390/ I'll push a 6-3 change after it is merged and I guess it'll be fixed in 6.3.1. And this is definitely no old / driver related bug. The patch is correct to handle non-RTL documents in an RTL UI or visa versa, but it needs adaption to the scroll wheel and smooth scroll handling on all platforms to work correctly, which is a larger effort.
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/a0a6a7e60ee499ffd82a57b899ca5f4981f0ab2f%5E%21 tdf#126680 Revert "VCL make horizontal scrolling depend on RTL" It will be available in 6.4.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.
*** Bug 126891 has been marked as a duplicate of this bug. ***
Jan-Marek Glogowski committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/192d9a2dc41d83c11ec7d5e3efda60a59c89f6ff%5E%21 tdf#126680 Revert "VCL make horizontal scrolling depend on RTL" It will be available in 6.3.1. 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.
Thanks. As best I can tell, not that I'm confident I remember how to scrounge around the daily builds, it hasn't made it into a Mac build yet. I see Unix and Win, but no Mac version. I'll check back in a week or so and meanwhile use 6.2.6.2.
LibreOffice Nightly builds for macOS are dead currently, which means this fix will be available in 6.3.1.x which is due 25th aug - 1st sept: https://wiki.documentfoundation.org/ReleasePlan https://dev-builds.libreoffice.org/daily/master/MacOSX-x86_64@49-TDF/
*** Bug 127018 has been marked as a duplicate of this bug. ***
*** Bug 127064 has been marked as a duplicate of this bug. ***
*** Bug 127074 has been marked as a duplicate of this bug. ***
*** Bug 127079 has been marked as a duplicate of this bug. ***
*** Bug 127089 has been marked as a duplicate of this bug. ***
*** Bug 127360 has been marked as a duplicate of this bug. ***
Bug still exists on MacOS 10.14.6, Mojave, with Libreoffice 6.3.1.2 and now on 6.2.7.1 Please fix.
(In reply to Cliff from comment #27) > Bug still exists on MacOS 10.14.6, Mojave, with Libreoffice 6.3.1.2 and now > on 6.2.7.1 Please fix. Hi Cliff - Scrolling works correctly / the bug is fixed on my system since 6.3.1.2 RC: Version: 6.3.1.2 Build ID: b79626edf0065ac373bd1df5c28bd630b4424273 CPU threads: 12; OS: Mac OS X 10.14.6; UI render: default; VCL: osx; NB I have my Mac settings: Preferences > Trackpad > Scroll & Zoom (unchecked) Scroll direction: Natural
You are correct. I don't know why I thought it was still wrong when I tested. Sorry for the noise.