Hello roee, *, Thanks for reporting a bug in LibreOffice. It's unclear from the information you provided exactly what's going wrong. Could you please give us more details, including clear steps to reproduce the problem? Thanks, Thomas.
I tested in both LibreOffice Calc and Writer, the touchpad two-finger-scrolling works as expected. Fedora 20 x86, Lenovo R61i, LibreOffice 4.2.3.3 As the bug reporter reported the OS as Windows, should someone test it under Windows also?
Steps to reproduce: Open up Calc. First let's demonstrate two-finger scrolling in the vertical axis, which works as expected: - On the touch pad, perform a two-finger scrolling gesture in an upwards direction. - This drags the sheet up, bringing a part of the sheet from further down into view. This is as expected. - On the touch pad, perform a two-finger scrolling gesture in a downwards direction. - This drags the sheet down, bringing a part of the sheet from further up into view. This is as expected. So in the vertical axis, two-finger scrolling works as expected. Now do the same test with two-finger scrolling in the horizontal axis, which doesn't work as expected: - On the touch pad, perform a two-finger scrolling gesture from left to right. - This drags the sheet to the left, bringing a part of the sheet from further right into view. This is opposite of what is expected. - On the touch pad, perform a two-finger scrolling gesture from right to left. - This drags the sheet to the right, bringing a part of the sheet from further left into view. This is opposite of what is expected.
(In reply to comment #3) > - On the touch pad, perform a two-finger scrolling gesture from left to right. > > - This drags the sheet to the left, bringing a part of the sheet from > further right into view. This is opposite of what is expected. I dont agree with you. two-finger scrolling gesture from left to right = dragging the scroll bar right = more contents on the right side show up. This is what we expect, and it is what any other applications behave. > - On the touch pad, perform a two-finger scrolling gesture from right to left. > > - This drags the sheet to the right, bringing a part of the sheet from > further left into view. This is opposite of what is expected. this is also what we expect. So, not a bug. Anyway, I dont think libreoffice can determine the touchpad guesture issue. It may be up to your touchpad driver settings?
Some more info : Based on my experience, on mobile phone screens, two figure scroll left-to-right will move the screen left-to-right. However touchpad of a notebook is different - it moves the scroll bar left-to-right, rather than move the content left-to-right. Applications just like firefox behave the same way.
I'm sorry, no, I think you're incorrect. It is not a touch pad issue, and the behavior you're describing is not what's expected. 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. This is a bug, and needs to be fixed for LibreOffice to be 1) self-consistent, and 2) consistent with expected behavior across all applications. I will again describe the behavior, this time including also the behavior of the scroll bars for further clarity. Please read this carefully: To reproduce: Open any LibreOffice application. Perhaps Draw makes this most clear. First let's demonstrate two-finger scrolling in the vertical axis, which works as expected: - On the touch pad, perform a two-finger scrolling gesture in an upwards direction. --> The vertical scroll bar moves down and the sheet moves up, bringing a part of the sheet from further down into view. This is as expected. - On the touch pad, perform a two-finger scrolling gesture in a downwards direction. --> The vertical scroll bar moves up and the sheet moves down, bringing a part of the sheet from further up into view. This is as expected. Now do the same test with two-finger scrolling in the horizontal axis, which doesn't work as expected: - On the touch pad, perform a two-finger scrolling gesture from left to right. --> The horizontal scroll bar moves right and the sheet moves left, bringing a part of the sheet from further right into view. This is opposite of what is expected. - On the touch pad, perform a two-finger scrolling gesture from right to left. --> The horizontal scroll bar moves left and the sheet moves right, bringing a part of the sheet from further left into view. This is opposite of what is expected. Again, the expected behavior, in either axis, is that the sheet moves with the gesture, not the scroll bar.
(In reply to comment #5) > Some more info : > > Based on my experience, on mobile phone screens, two figure scroll > left-to-right will move the screen left-to-right. However touchpad of a > notebook is different - it moves the scroll bar left-to-right, rather than > move the content left-to-right. Applications just like firefox behave the > same way. I respectfully disagree. I'm running on a notebook (currently an HP Envy running Win8.1). I just tried this in Firefox, since you mentioned it. Firefox behaves correctly per my definition. The sheet, not the scroll bar, moves with the gesture.
never confirmed so reopened is incorrect
(In reply to 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. This behavior is configurable on my touchpad under Linux. I guess it is configurable on Windows too. Best regards. JBF
Yes, there is a setting in Windows to globally reverse the direction. However, this not the point. Whichever way Windows is configured, LibreOffice will behave the opposite way of all other applications under that configuration. So I can reverse the global setting in Windows to make LibreOffice behave "correctly", but then all other applications behave incorrectly. To re-iterate, we don't need to debate which direction is "right" or "wrong". As you pointed out, that preference can be changed in a global setting in the OS. The problem is the inconsistency among applications -- that LibreOffice does the opposite of all other applications. Cheers, -Roee (In reply to comment #9) > (In reply to 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. > > This behavior is configurable on my touchpad under Linux. I guess it is > configurable on Windows too. > > Best regards. JBF
On a Lenovo T520 with Win 7, two-finger scrolling in Firefox scrolls vertically exactly like LO and Windows file explorer (fingers down, scrollbar down..). Horizontal scrolling in LO, however, does not do anything. In Firefox as in file explorer, horizontal scrolling left moves the scrollbar left, right moves the bar right. So it seems the reporter's claim of standard behavior does not hold water. The behavior is apparently device-specific or OS-specific. At least on my Lenovo, two-finger scrolling is not about moving freely on a canvas in 4 directions. It is simply scrolling, like the name and the cursor helpers imply.
Comparing roee and Beluga: (In reply to roee from comment #7) > I respectfully disagree. I'm running on a notebook (currently an HP Envy > running Win8.1). I just tried this in Firefox, since you mentioned it. > Firefox behaves correctly per my definition. The sheet, not the scroll bar, > moves with the gesture. (In reply to Beluga from comment #11) > On a Lenovo T520 with Win 7, two-finger scrolling in Firefox scrolls > vertically exactly like LO and Windows file explorer (fingers down, > scrollbar down..). Horizontal scrolling in LO, however, does not do anything. > In Firefox as in file explorer, horizontal scrolling left moves the > scrollbar left, right moves the bar right. Roee: Can you confirm the behavior Beluga describes in comment #11? Please make sure to include the version of Firefox that y'all are using in your tests. Thanks! Status -> NEEDINFO
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/FDO/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team This NEEDINFO message was generated on: 2015-10-14
As I've already described previously, no, what I'm seeing contradicts what Beluga reported in Firefox, as well as in Windows File Explorer. I'm currently using Firefox version 41.0.1. And the correct behavior as I've described has been unchanged with every version for at least the past couple of years. Likewise with Adobe Acrobat (currently version 15.9.20069.159242) Likewise with Internet Explorer (currently version 11.0.9600.18036) Likewise with any other common piece of software I could think to try. Take your pick. Only LibreOffice is the oddball exception that doesn't work correctly.
...the message says "mark the bug as UNCONFIRMED" else the autobot will INVALIDATE your bug...thus the express statement to read everything. Fortunately I caught this in my email else it would have gone away.
Seems to be confirmed and fixed: https://gerrit.libreoffice.org/gitweb?p=core.git;a=commitdiff;h=b083afac2f0531bacd790cb3ac25353f9a02db5d Best regards. JBF
let's mark it as fixed then. feel free to reopen if the bug persists
The horizontal scroll direction is non-standard (reversed from all other Windows applications). Test: Open LibreOffice Calc. 1. scroll vertically - it will match the behaviour of the UI of other Programs in Windows. 2. scroll horizontally - it will be the reverse of all other UIs of other Programs in Windows. NOTE: this is independent of Global User settings on scroll direction (reversed vs. natural scrolling). LibreOffice Calc is _always_ the opposite of all other applications.
Dear Marlen, This bug has been in RESOLVED FIXED status for more than 6 months. If the issue is still reproducible with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/, please report a new issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, if needed, the steps and documents to reproduce it. Thanks for your understanding and collaboration. Closing as RESOLVED FIXED
(In reply to Xisco Faulí from comment #19) > Dear Marlen, > This bug has been in RESOLVED FIXED status for more than 6 months. > If the issue is still reproducible with the latest version of LibreOffice > from https://www.libreoffice.org/download/libreoffice-fresh/, please report > a new issue in https://bugs.documentfoundation.org/enter_bug.cgi providing, > if needed, the steps and documents to reproduce it. > Thanks for your understanding and collaboration. > Closing as RESOLVED FIXED
You guys closed this bug prematurely. It was never fixed. The code change pointed to in comment #16 does nothing to address this issue. And the symptom is still reproducible, and has been all along. I continue to see it in various versions of LibreOffice up to and including the current version, running on various different flavors and versions of both Windows and Linux.
It is true, the code change only affects GTK3.
It would be great if enabling scroll comes a modifiable setting. Users can customize so that no one feels scroll behavior is odd.
The alleged bug still persists in LO 6.2 beta... To reiterate, global OS settings (Linux Mint) for scrolling go one way, LO follows the opposite way, which is rather annoying but not an impossible thing to live with.
Steps to Reproduce: 1. With a LO Writer or Calc document, zoom in and/or resize your window to show horizontal scroll bars. 2. Two-finger drag from right to left Expected Results: 1. Document scrolls to the right Actual results: 1. Document scrolls to the left This appears to be a problems with Synaptics touchpad drivers found in Lenovo laptops. I could reproduce this on my T440. I could not reproduce this on my Asus laptop with Asus drivers nor on my Dell with MS precision touchpad drivers. With my T440, Word, Excel, MS Paint, Firefox, Chrome, Photoshop, WordPerfect, Notepad all 2-finger scroll correctly. LibreOffice is the only application that does not respect the drivers settings. See Also: https://ask.libreoffice.org/en/question/155824/two-finger-horizontal-scroll-does-not-reverse/
On ubuntu 18.04 with the libinput driver, I tested all 3 laptops. All of them had the correct horizontal scrolling behavior. So lets track the Windows / Synaptics issue here. nokidding, Can you file a new bug report and give as much info as possible. Need to know what touchpad hardware you have, what driver (libinput or synaptics), and what VCL backend (gtk or gtk3) you are using.
(In reply to Luke from comment #26) > On ubuntu 18.04 with the libinput driver, I tested all 3 laptops. All of > them had the correct horizontal scrolling behavior. > > So lets track the Windows / Synaptics issue here. > > nokidding, > Can you file a new bug report and give as much info as possible. Need to > know what touchpad hardware you have, what driver (libinput or synaptics), > and what VCL backend (gtk or gtk3) you are using. nokidding was not in CC, so asking again. We are getting new reports against Linux, though (gtk2): bug 126680
MacOS with LibreOffice version 6.3.0. has the same incorrect horizontal scrolling behavior. 6.2.6.2 on MacOS works as expected, 6.3.0 does not.
Same bug is in 6.3.0.4 in Calc on Mac OS 10.13.6. I've been too busy with a variety of things to keep current on LO versions. The most recent one I've used before this was 6.1.0.3 and two-finger scrolling on the trackpad works as it is supposed to there. It was immediately obvious when I moved up to 6.3.0.4 and starting working with a spreadsheet that there was something wrong with the horizontal scrolling. Hardware is a 13" MacBook Pro Retina. I looked for other reports of the bug and the one this comment is attached to is the only one I found. Should there be a new bug report that isn't hardware specific?
Gym and Ted see Bug 126680. The 6.3.0.4 issue on Mac OS should have been fixed there. It was backported to 6.3.1.
(In reply to Luke from comment #30) > Gym and Ted see Bug 126680. The 6.3.0.4 issue on Mac OS should have been > fixed there. It was backported to 6.3.1. Thanks. See comment I made on 126680 (the fix doesn't seem to have made it in to a Mac build yet.)
Is there a way to make this a setting? My expected behavior is the pre-fix behavior where trackpad scrolling right to left moves the scrollbar to the left. This is how all my other applications behave. I think this is a Windows/Driver setting that LibreOffice is not respecting. Vertical scrolled works as expected.
Dear roee, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug