Description: Edge Scrolling no longer works properly on my touchpad beginning with version 6.2 and newer. Steps to Reproduce: 1.edge scrolling going toward row 1 works fine 2.edge scrolling going down the spreadsheet only moves a few rows at a time if at all. 3. Actual Results: same as box above Expected Results: nothing Reproducible: Always User Profile Reset: Yes Additional Info: I am now using the last version before version 6.2 as an Appimage and it works fine.
I tried this on MX-Linux version 19.4 and Linux Mint 20.1 and get the same results of not scrolling properly.
I don't understand: 1. you are not clear which is the last version tested, please try Appimage daily master 7.3+ 2. please make a Screencast of right and wrong behavior 3. if this depends on file, please attach a file
I tried this on LibreOfficeDev-7.3.0.0.alpha0_2021-06-17.standard-x86_64.Appimage. I still get the same error in Calc. The edge scrolling with my touchpad does not work properly. You can not scroll down the spreadsheet. It scrolls up fine. I also tried this with Libre Writer and it works fine. I tested a lot of versions to see when this bug first appeared. It seems that all versions before version 6.2.0 works fine and all versions starting with 6.2.0 no longer work properly in Libre Calc wuth edge scrolling. I also tried 2-finger scrolling instead of edge scrolling and this works fine. Thus there is something wrong with edge scrolling. I also reproduced this error with different linux distributions. I can not give you a screen shot of the error.
I can confirm this behavior (scrolling down and right work, but up and left are slower or impossible, depending on scroll speed)--it seems to be tracked downstream by Red Hat here: https://bugzilla.redhat.com/show_bug.cgi?id=1686593 Investigating the code, my guess is that the way `ScGridWindow::ScrollPixel` works, it resets the intra-cell scroll offsets to 0,0 (I can't tell if this happens in `ScGridWindow::GetDrawMapMode` or in `ScGridWindow::ScrollPixel`, or just by merit of not tracking pixel offsets when not in `MapMode(MapUnit::MapPixel)` map mode). But it seems that this bug is a side effect of the known hackiness (see comments in `ScGridWindow::GetDrawMapMode` and `ScGridWindow::DrawContent`) of the way `ScGridWindow` does scrolling. It might be possible to fix the directional asymmetry by simply making `ScGridWindow::ScrollPixel` initialize its pixel offsets to the center of a cell rather than the top-left before applying the scroll dx/dy it gets.
No repro with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 1c0aa970650ffc7c749e0b5ea655ebb2d137c8ae CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded Jumbo
I can still reproduce this with LibreOffice calc 7.4.2 as packaged by Arch Linux ("LibreOffice 7.4.2.3 40(Build:3)" from `libreoffice --version`). I'm using a wlroots-based Wayland compositor. In addition to the behavior with edge scrolling, similar behavior (caused almost surely by the same underlying bug) is reproducible with two-finger scrolling: slow scrolls downward do nothing, while slow scrolls upward move relatively quickly. Scrolling quickly works in both directions. (In reply to raal from comment #5) > No repro with Version: 7.4.0.0.alpha0+ / LibreOffice Community > Build ID: 1c0aa970650ffc7c749e0b5ea655ebb2d137c8ae > CPU threads: 4; OS: Linux 5.11; UI render: default; VCL: gtk3 > Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US > Calc: threaded Jumbo What did you do to attempt to reproduce, in which environment, and what did you observe? Please be detailed.
I'm not using wayland, but x11. Ubuntu 22.04 adding cc to Caolán, Redhat's bug was assigned to him.
I dug in here and figured out the problem: `lcl_HandleScrollHelper` is using `o3tl::saturating_cast` to handle scroll deltas, which results in positive/negative asymmetry. The asymmetry can be fixed by simply adding 0.5: `nNewPos = o3tl::saturating_cast<tools::Long>(fVal + 0.5);` in `lcl_HandleScrollHelper` in `vcl/source/window/window2.cxx`. But looking at this code, it really should be properly handling sub-cell scrolls. I've written a patch that stores partial scroll offsets in `WindowImpl` and uses them in `Window::HandleScrollCommand`; this cleanly fixes this bug and improves smoothness of scrolling in general for touchpads.
Created attachment 183655 [details] Patch that fixes the bug. Developed against libreoffice-core commit 0eec6d44c65f895c6fe2172792717418627db05d. I'd like code review for this patch and mentorship to shepherd it into a release if possible.
(In reply to jeyov45316 from comment #9) > Created attachment 183655 [details] > Patch that fixes the bug. Developed against libreoffice-core commit > 0eec6d44c65f895c6fe2172792717418627db05d. > > I'd like code review for this patch and mentorship to shepherd it into a > release if possible. Thanks for the patch! If possible could you submit it to our code review system: https://wiki.documentfoundation.org/Development/gerrit/setup https://wiki.documentfoundation.org/Development/gerrit/SubmitPatch If you need help, you can contact me via email.
Jonas Eyov committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/fe21365c5a9083ae1f086ea48614263b3a75ab3e tdf#143209 vcl: track partial scroll deltas It will be available in 7.5.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.
Jonas Eyov committed a patch related to this issue. It has been pushed to "libreoffice-7-4": https://git.libreoffice.org/core/commit/3dcea050438ace1ace5e013c0c7326aec3c82c6b tdf#143209 vcl: track partial scroll deltas It will be available in 7.4.4. 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.