Description: hi, i have the following problem: 1. scrolling with a mouse is fine in LibreOffice 2. Scrolling with a laptop keypad is way too fast - so fast it's unusable 3. scrolling with keypad in other programmes is fine, so slowing down overall keypad scrolling would solve Libreoffice scrolling but would make scrolling in those other programmes too slow Rik Steps to Reproduce: 1. use the keypad to scroll in LibreOffice Writer 2. 3. Actual Results: srolling is too fast Expected Results: scrolling should be normal speed Reproducible: Always User Profile Reset: No Additional Info:
Please tell us the laptop model. Have you seen this in versions older than 6.0.6? Set to NEEDINFO. Change back to UNCONFIRMED after you have provided the information.
lenovo t480
sorry i have just 1 version of Libre Office, the most current stable version Rik
Assuming you mean touchpad and correcting summary accordingly.
yep the touchpad, sorry
I also get this problem and my laptop is ASUS X550JX in Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
I have verified on my laptop, the bug is present on x64.
*** Bug 121684 has been marked as a duplicate of this bug. ***
*** Bug 122769 has been marked as a duplicate of this bug. ***
*** Bug 119523 has been marked as a duplicate of this bug. ***
I have exactly the same issue, with an Asus vivobook
(In reply to alopfr from comment #11) > I have exactly the same issue, with an Asus vivobook Please copy and paste here the contents of your Help - About. This allows us to know more about your system.
(In reply to Buovjaga from comment #1) > Please tell us the laptop model. > Have you seen this in versions older than 6.0.6? > > Set to NEEDINFO. > Change back to UNCONFIRMED after you have provided the information. Hi, I have a ASUS ZenBook UX430UA I have the Libre Office version 6.2.3.2 I have this bug of the track pad way too sensitive that make the scrolling way too fast
About the bug of the scrolling too fast with track pad, I use Writer most of the time, for the rare time I use other apps of Libre Office I haven't notice something like that. So this bug is on Writer for sure, other apps I'm not sure sorry.
*** Bug 130303 has been marked as a duplicate of this bug. ***
I have the same problem on my Acer Swift 3, windows 10. It's very unpleasant and makes the software unusable when I'm on the go.
I'm experiencing a similar bug, I'm not sure if it is duplicate. Horizontal scrolling using a touchpad is too fast after resizing the page (changing width/height) in Impress (Slides > Properties > Paper Format) or Draw (Page > Properties > Paper Format). The laptop is Thinkpad X1 Carbon Gen 7, operating system Ubuntu 20.04, Libreoffice version 6.4.3-0ubuntu0.20.04.1. Thanks, Giorgis
*** Bug 131954 has been marked as a duplicate of this bug. ***
I have this problem also, Dell XPS 17 9700 (2020 Model) Microsoft Precision Touchpad. Mouse operation is fine, trackpad scrolls way to fast in Writer and Calc and all Libre Office Components. Info: Version: 6.3.6.2 (x64) Build ID: 2196df99b074d8a661f4036fca8fa0cbfa33a497 CPU threads: 12; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US
I also have access to a XPS 15 Model Precision 5520 running Win 10, so I loaded Libre Office V6.3.6.2 (X64) on it and it does NOT have the scrolling issue. This PC also uses the precision touchpad driver as the XPS 17 that I tested above. So it appears that the Precision touchpad driver on its own is not the root cause of the problem, there is something about the actual touch pad hardware also.
This is also happening on Thinkpad 490s In the old 6.4 and also in : Version: 7.0.1.2 Build ID: 00(Build:2) CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.0.1_rc2-0ubuntu0.20.04.1 Calc: threaded Scrolling i choppy.. In freeoffice and other applications it works fine.
*** Bug 139277 has been marked as a duplicate of this bug. ***
I set High because there are 5 duplicates here, separate Linux bugs, similar bug 35285.
Timur is there a reason why you didn't mark 106008 as a duplicate and instead added to the "See Also" list?
(In reply to Severo Raz from comment #24) > Timur is there a reason why you didn't mark 106008 as a duplicate and > instead added to the "See Also" list? This one is marked Windows and that one Linux. Not sure if it makes a difference from dev PoV.But it thought it's better to remain split so far. Even now there are enough duplicates and followers for this annoyance to be considered High - but still it takes a volunteer dev to work on that, so no time-frame. Unless someone can find one and get him/her here.
I still have this problem with LibreOffice 7.1 on my Lenovo 80VF. This makes LO unusable :( Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 19041; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
*** Bug 140407 has been marked as a duplicate of this bug. ***
Also have this problem. Unusably fast touchpad for Writer and Calc (at least). One of a few deal breakers getting a team to adopt libreoffice. Lenovo Legion 5 Win 10 64
Please somebody fix this!! Tony
Same bug on Asus ROG flow x13 running Windows 10 v. 10.0.1943 Build 19043 using LibreOffice v. 7.2.1.2. Same LibreOffice version on the same laptop on Arch runs perfectly with smooth consistent (with the rest of the system) scrolling.
Guess this needs to be set ALL since the Linux os/DE issues are being pointed here as well, and we are treating bug 85677 for touch gestures as generic even though solutions for each os will require native code.
Same issue on a Samsung Book S with Windows 11 21H2 OS Build 22000.348. I can't use my laptop's touchpad with any LibreOffice 7.2.4.1 application.
Also appies with some scroling software. I use Scroll+ on MacOS.
Same issue with LO Writer and Calc. In Calc, scrolling up/down and left/right is super fast/sensitive. In Writer, scrolling up/down is good. But Ctrl + up/down + 2 finger scroll (zoom in/out) is too sensitive to be able to use in both Calc and Writer. XPS13 9370 Not sure what the trackpad hardware details are. I don't know which output entry from lspci/lsusb refers to the trackpad. Ubuntu 20.04 LO 6.4.7.2 Ian
Same issue on Arch linux scroll is absolutely broken on calc, here are some specs... Connected touchpad (xinput list | grep Touchpad): ⎜ ↳ MSFT0001:02 06CB:CD3E Touchpad id=15 [slave pointer (2)] Touchpad settings (/etc/X11/xorg.conf.d/81-touchpad.conf): Section "InputClass" Identifier "Trackpad" Driver "libinput" MatchIsTouchPad "true" Option "NaturalScrolling" "true" Option "Tapping" "on" Option "ClickMethod" "clickfinger" Option "AccelSpeed" "0" Option "ScrollPixelDistance" "50" Option "TransformationMatrix" "4.5 0 0 0 4.5 0 0 0 1" Option "DisableWhileTyping" "false" EndSection
Same issue. Too fast scroll with touch pad in Writer. Documents is DOCX format. Device: Thinkspad t480s, windows 11
This is the effect of per-N-pixel scrolling, not pixel-by-pixel. To get what I mean, look at the difference between scrolling in LibreOffice and in a web browser. Also, some Office applications apply some kind of 'delay' to the scroll bars to make it feel more 'mechanical'. To get what I mean, scroll through the left sidebar of PowerPoint.
This website shows error on laptop search. https://www.laptoppub.com/
I have the same as OP (rik@oemail.nl, 2018-09-17 10:20:42). Scrolling in LibreOffice Writer using two fingers on the touchpad is so sensitive that even a slight movement of the fingers scrolls much more than a screenful, and I have no idea where I am, or how I get back to where I was. Trying to scroll back by the same amount, races past where I was. Using the touchpad in other programs (e.g. Chrome browser), works fine. Dragging two fingers across the height of the touchpad scrolls the screen about one-half screenful. Scrolling using a mouse wheel in LibreOffice Writer works nicely just like in Chrome. I am using: Version: 7.2.6.2 (x64) / LibreOffice Community Build ID: b0ec3a565991f7569a5a7f5d24fed7f52653d754 CPU threads: 8; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: nb-NO (nb_NO); UI: nb-NO Calc: CL Platform: ASUS VivoBook 17, AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx, 2100 Mhz, 4 kernels, 8 logical processors, Microsoft Windows 11 version 10.0.22000 Build 22000
I just installed 7.3.4. Scrolling is fast, but usable on my Lenovo Legion 5.
Also experiencing this on my Lenovo Yoga 520 with version 7.2.7, running windows 10 64bit. With a 122 long document page, one scroll motion of the touchpad (from bottom to top) will send me past 5 pages in Writer. (btw I'm new to bugzilla, apologies if I've messed something up while making this comment)
This is a serious problem for office work. Affecting my machine as well. System info: Edition Windows 11 Pro Version 21H2 OS build 22000.978 Experience Windows Feature Experience Pack 1000.22000.978.0 Libreoffice: Version: 7.4.0.3 (x64) / LibreOffice Community Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a CPU threads: 16; OS: Windows 10.0 Build 22000; UI render: Skia/Vulkan; VCL: win Calc: CL
Dell XPS Come on this is taking ages, some of the semi-workarounds have over 5000 views, there are tonnes of duplicates across many websites... it's been happening since 2017-18 and makes the entirity of libreoffice writer nearly impossible to use on a laptop.
I am having the same issue. Laptop is Dell Inspiron 5577. Scrolling using the Laptop's touchpad is too fast, both vertically and horizontally (when using sheets).
I'm experiencing this problem on an ASUS VivoBook 17 / Win10 (everything system- and driver- and LO-wise up to date), with a wireless Logitech M185 mouse. In the year of our lord two thousand and twenty-two, this should not still be a problem for so many users.
(In reply to Ian Hodgson from comment #36) > Same issue with LO Writer and Calc. In Calc, scrolling up/down and > left/right is super fast/sensitive. In Writer, scrolling up/down is good. > But Ctrl + up/down + 2 finger scroll (zoom in/out) is too sensitive to be > able to use in both Calc and Writer. > > XPS13 9370 > > Not sure what the trackpad hardware details are. I don't know which output > entry from lspci/lsusb refers to the trackpad. > > Ubuntu 20.04 > > LO 6.4.7.2 > > Ian It seems likely that there are multiple underlying issues being tracked in this bug report; for the one you mention (calc scroll up/left is fast, down/right is slow), I've developed a patch; see <https://bugs.documentfoundation.org/show_bug.cgi?id=143209>.
My scroll wheel for movement in a sheet is too much per click. Scroll slide moves it 1 row which is better unless your rows are tall. I looked at what was happening and it seems the issue is with how many rows/click are moved. The default seems to be 3 rows/click. I am looking for a way to set this or have it be a function of the screen rather than rows. Rows as the resolution fails because it it variable due to content and/or zoom. If I am zoomed in then 3 rows can be a lot of movement and I jump over data. If I have tall rows with a lot of content then 3 rows is too much and I jump over data. I would propose a simple initial fix to be the ability to set the rows per click. Somewhere there is a number that controls this. A slightly better fix would be rows/click with a zoom percentage adjusted. For example if set for 3 rows per click and a zoom of 200% would give 3/2 or 1.5 rows. This does not solve the issue of the row height. Optimal solution using native LO controls would be if the Grid could be used, This would solve both. Ability to set number of grid rows per click. The grid already has the ability to set its horizontal and vertical height. Both of these offer a means of controlling the amount of screen that is moved per click.
Hello. I've got the same problem: the slightest scrolling movement on the touchpad scrolls a Calc sheet by about 12 columns or rows. This makes using the touchpad for scrolling unusable. Besides, very often when scrolling several times in a Calc sheet, LibreOffice freezes, then the whole computer becomes unresponsive and finally LibreOffice crashes. (The 'Send crash reports to The Document Foundation' option is activated, so i hope you've gotten the reports.) LibreOffice version information: Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: de-CH (en_CH); UI: en-GB Calc: threaded Additional system information: Pointing device: Synaptics PrecisionTouchpad Filter Driver
*** Bug 152586 has been marked as a duplicate of this bug. ***
I have this bug also. In LibreOffice Calc, scrolling vertically or horizontally using the touchpad two-finger scroll is way too fast. Lenovo Legion Y740-17IRHg, Windows 10 Home. If I move my fingers the *smallest* amount possible that registers on the touchpad (~1 mm), the spreadsheet moves 3 rows vertically at a minimum. But any normal movement that scrolls a little in other apps results in most of a screen going by in Calc. About dialog: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Same here. Scrolling using the touchpad in other apps is as expected, but in LibreOffice Writer (for example) the scrolling is much more 'aggressive' - much more movement than expected. Hardware: HP ZBook Fury 15 G7. LibreOffice Version Information: Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 12; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-GB (en_GB); UI: en-GB Calc: threaded
While researching why LO was crashing on my laptop, I unchecked "Use Skia for all rendering" under Graphics Output (Tools-Option-View) and noticed a definite improvement in the scroll speed. It's not OpenOffice slow like I'd prefer, but it's a considerable improvement compared to what it was.
(In reply to SR from comment #55) > While researching why LO was crashing on my laptop, I unchecked "Use Skia > for all rendering" under Graphics Output (Tools-Option-View) and noticed a > definite improvement in the scroll speed. It's not OpenOffice slow like I'd > prefer, but it's a considerable improvement compared to what it was. I confirm that disabling Skia slows down touchpad scrolling on my laptop as well.
(In reply to SR from comment #55) > While researching why LO was crashing on my laptop, I unchecked "Use Skia > for all rendering" under Graphics Output (Tools-Option-View) and noticed a > definite improvement in the scroll speed. It's not OpenOffice slow like I'd > prefer, but it's a considerable improvement compared to what it was. (In reply to alec.lownes from comment #56) > (In reply to SR from comment #55) > > While researching why LO was crashing on my laptop, I unchecked "Use Skia > > for all rendering" under Graphics Output (Tools-Option-View) and noticed a > > definite improvement in the scroll speed. It's not OpenOffice slow like I'd > > prefer, but it's a considerable improvement compared to what it was. > > I confirm that disabling Skia slows down touchpad scrolling on my laptop as > well. Assume you both are on Windows builds? We'd be more interested in knowing if rather than disabling Skia Vulkan rendering, you instead mark the "Force Skia software rendering" checkbox to shift to raster framing. GDI+ of default rendering has other affects on the UI (e.g. the Render context refactoring of META bug 91488 and Flickering UI of META bug 112889).
(In reply to V Stuart Foote from comment #57) > (In reply to SR from comment #55) > > While researching why LO was crashing on my laptop, I unchecked "Use Skia > > for all rendering" under Graphics Output (Tools-Option-View) and noticed a > > definite improvement in the scroll speed. It's not OpenOffice slow like I'd > > prefer, but it's a considerable improvement compared to what it was. > > (In reply to alec.lownes from comment #56) > > (In reply to SR from comment #55) > > > While researching why LO was crashing on my laptop, I unchecked "Use Skia > > > for all rendering" under Graphics Output (Tools-Option-View) and noticed a > > > definite improvement in the scroll speed. It's not OpenOffice slow like I'd > > > prefer, but it's a considerable improvement compared to what it was. > > > > I confirm that disabling Skia slows down touchpad scrolling on my laptop as > > well. > > Assume you both are on Windows builds? > > We'd be more interested in knowing if rather than disabling Skia Vulkan > rendering, you instead mark the "Force Skia software rendering" checkbox to > shift to raster framing. GDI+ of default rendering has other affects on the > UI (e.g. the Render context refactoring of META bug 91488 and Flickering UI > of META bug 112889). At least on my Windows laptop setup, there is no difference between checking or unchecking the "Force Skia software rendering" checkbox. Both still show too-fast scrolling.
*** Bug 155064 has been marked as a duplicate of this bug. ***
Same issue: Dell XPS 9500 (2021) on Ubuntu 22. Trackpad scrolling in Office Libre is exaggerated to the point of massive inconvenience. In Calc especially it is just totally out of control, its a horrific mix of "sticky" and over-scrolling. I'll swipe two fingers as slow as I can and it just sits there, and then I slowly ramp up speed to try to get to some point where it is just barely moving and it skips from not moving at all to scrolling like three pages to the right with no in-between. Then I have to try the slow build up all over again in the other direction to try and get back to where I was: stuck, stuck, stuck, stuck, stuck,*WARP FACTOR 10 ENGAGE!*. And now have to try it again in the other direction, repeat ad nauseam. I am spending more of my time in Calc trying to scroll to the right place than doing actual work, its unusable like this. The developers don't need to redo the system, if they could just add some numeric variables with a wide range that users could poke around with on their own in the options dialogue -- under say "General," or even better, one set of trackpad scroll adjustment options for each of the Office sub-programs as they all seem to handle trackpad scrolling in different ways at different levels of frusterating exaggeration -- that small addition alone could fix everything. Literally, one would just go to options and put in like a "0.02" on the column horizontal scroll adjustment and a "0.1" on the column vertical scroll adjustment (or whatever feels right for your setup) and be done with it. Problem solved, programming time involved: like 1 hour tops, duration of solution based on future updates: forever, value of 1 hour of work done: completely priceless, gratitude from users: eternally grateful.
*** Bug 157694 has been marked as a duplicate of this bug. ***
(In reply to V Stuart Foote from comment #61) > *** Bug 157694 has been marked as a duplicate of this bug. *** Alright thanks for triaging, I didn't realize this was such an old issue. What is the status, is someone looking at this ? can I help in any way ?
Can not reproduce with a 7.6.2.1 release build on Windows 10 19045 build. Calc sheet 200 rows, 25 columns filled with random numbers. v-scroll "two finger swipe", h-scroll "two finger swipe" both reasonable default rate 1-3 rows/columns, accelerating with a "flick". Likewise Writer doc, 30 pages of the "dummy text" paragraphs. v-scroll 3-5 lines in controllable rate, accelerates scroll with a "flick". This is a generic Samsung laptop touchpad, using the default Windows MS HID mouse driver. PNP Device ID HID\ZNT0001&COL01\5&374CE970&0&0000 Driver C:\WINDOWS\SYSTEM32\DRIVERS\MOUHID.SYS (10.0.19041.1, 34.50 KB (35,328 bytes), 12/7/2019 4:07 AM) =-testing-= Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
Ok I just tried with my wife's Lenovo E560 from 2016, and there's no issue. Here is a quick info dump from Windows' "device manager" : ThinkPad UltraNav Driver provider : AlpsAlpine Driver version : 8.216.1616.174 On my laptop (which encounters the issue), the same place says : IHM mouse Driver provider : Microsoft Driver version : 10.0.19041.1 I'm not sure that is helpful at all. I should mention that it is a much more sensitive trackpad than hers. I don't really know how a trackpad works, but my understanding is that trackpads have a set resolution/matrix. If the program somehow reads the input from the trackpad as absolute, instead of relative to the trackpad's resolution, it might explain the difference in sensitivity. If I'm not being totally clear, here is an example : trackpad A and trackpad B both have the same effective area, but trackpad B has a denser matrix, hence finer-grained detection -so, for the same effective distance travelled by fingers, it sends twice as many scroll events to the program. There should be some sort of remapping, I guess, using the trackpad matrix density as a divider. I can only assume this information exists and is available because any other programs I use do not suffer from the issue. What do you think, does that make any sense ?
I have been experiencing this bug (or design flaw) for a while now, but I have not bothered to create a bugzilla account and report my experience until now. I am merely a casual libreoffice user, if there is such a thing, and therefore I likely know the least among everyone here as to how libreoffice or even software/programming in general works. I mainly just use Writer. In my case, I operate an LG Gram laptop with Windows 10, Version 10.0.19045, Build 19045. My current libreoffice installation is version 7.5.5.2, but as I have said before I have had this issue for a while now and indeed experienced it in recent, past versions. If I can provide anymore information that would be useful, please let me know. As others have reported, when I scroll through a libreoffice document with a trackpad (in my case in Writer) I jump several lines away from the line that I wanted to read, edit, or write. The scrolling is highly sensitive. I have grown so accustomed to such sensitivity that I sometimes glide through dozens of pages in the larger documents I have written just for the fun of it (even though I could just use Navigator to jump to the section I need to see). At my gentlest touch, I can sometimes scroll to the subsequent line I want to read. It takes much effort and precision, though, and I more often than not skip over that next line I need to read. Yet, with any other application or software, in Microsoft Word (before I switched to Libreoffice) I can scroll just fine. I can smoothly scroll back and forth with ease. The contrast between scrolling in Libreoffice versus any other application is almost astoundingly bad, until one gets used to it. I hope that some talented developer/programmer, or someone in the main team of The Document Foundation, takes a look at this issue and assigns a fix to a future update. I do appreciate that Libreoffice is a community driven project, but I personally do not know anyone with the skill and permission to develop such a patch. I do not know who to contact, or if it is even possible to contribute to some kind of fund that would entice a willing developer. This bug is not of dire importance; it does not risk breaking the software. Yet, it does an incredible job of destroying Libreoffice's ease of use. And for someone like me, a person that sits on their butt all day writing on a latptop, such an issue is significant. (I write some of this in jest.)
I too experience this issue with Calc so far. I started using LibreOffice only recently and plan to gradually migrate completely to it. The scrolling speed is frustrating at the very least and I hope that it is addressed effectively soon. I use Win 11 Pro on Asus Zenbook Pro 15. My current version of LO is 7.5.9.2. I am downloading 7.6 which I understand to be a beta version of the next update.
(In reply to V Stuart Foote from comment #63) > Can not reproduce with a 7.6.2.1 release build on Windows 10 19045 build. > > Calc sheet 200 rows, 25 columns filled with random numbers. > v-scroll "two finger swipe", h-scroll "two finger swipe" both reasonable > default rate 1-3 rows/columns, accelerating with a "flick". > > Likewise Writer doc, 30 pages of the "dummy text" paragraphs. v-scroll 3-5 > lines in controllable rate, accelerates scroll with a "flick". > > This is a generic Samsung laptop touchpad, using the default Windows MS HID > mouse driver. > > PNP Device ID HID\ZNT0001&COL01\5&374CE970&0&0000 > Driver C:\WINDOWS\SYSTEM32\DRIVERS\MOUHID.SYS (10.0.19041.1, 34.50 KB > (35,328 bytes), 12/7/2019 4:07 AM) > > > =-testing-= > > Version: 7.6.2.1 (X86_64) / LibreOffice Community > Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 > CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: threaded I am taking the liberty to reply directly to you because you seem familiar with the project, which I am not. I see the bug has no assignee. Have steps been taken in identifying the hardware that is prone to encountering the issue? would you say that be a good first step in tackling it? I can't personally take a stab at it right now, I am extremely busy. Perhaps next year -but I would have to learn to code first, and I expect it will take some time before I'm competent enough to make sense of this particular problem. Otherwise, is there someone in charge of input handling specifically, that could serve as a mentor of sorts? Thanks, Hadrien
(In reply to Hadriscus from comment #67) > I am taking the liberty to reply directly to you because you seem familiar > with the project, which I am not. I see the bug has no assignee. Have steps > been taken in identifying the hardware that is prone to encountering the > issue? would you say that be a good first step in tackling it? > I can't personally take a stab at it right now, I am extremely busy. Perhaps > next year -but I would have to learn to code first, and I expect it will > take some time before I'm competent enough to make sense of this particular > problem. Otherwise, is there someone in charge of input handling > specifically, that could serve as a mentor of sorts? Thanks, Not input handling specifically, but I do the usual introduction to development (a few basic topics over several chats). We also have other mentors available. Regarding touchpads, Povilas Kanapickas worked on gestures last year as part of improving Linux touchpad experience. His work was not entirely specific to Linux. About Povilas's work in multiple projects: https://www.gitclear.com/blog/linux_touchpad_update_january_2023
I just want to jump in to point out that this isn't just touchpads, it also affects mouse scroll wheels. I clocked page scroll at 641kph (/s) using a logitech M185 and a Microsoft Wireless Mobile Mouse 4000. In other words, scrolling with any of these methods is unusable.
(In reply to jae lee from comment #69) > I just want to jump in to point out that this isn't just touchpads, it also > affects mouse scroll wheels. I clocked page scroll at 641kph (/s) using a > logitech M185 and a Microsoft Wireless Mobile Mouse 4000. In other words, > scrolling with any of these methods is unusable. Is this about pressing and holding the scroll wheel button specifically? Because it surely is not commonly seen when scrolling with the wheel. I don't see it when pressing and holding either.
The excessive scrolling speed also occurs in HORIZONTAL scrolling under certain conditions. Viewing the middle of a large text-only document in a left-half-screen window: - scroll up/dn using 2-finger swipe on touch pad = too fast (F) - scroll up/dn using click&drag-with-finger horizontal scroll bar = F - scroll up/dn using click&drag-with-joystick = F - scroll L/R using 2-finger swipe on touch pad = F - scroll L/R using click&drag-with-finger on horizontal scroll bar = Normal (N) - scroll L/R using click&drag-with-joystick = N "F" (fast) scrolls across the entire width/height of the screen when I move my fingers about 1/8 inch across/down the touch pad. Thinkpad Extreme Gen 2, windows 11 Home, Chrome, Libre Office 7.4.6.1,Dec 2023. Carrt7
I’ve similar problem. 1. Steps: In writer open a text document that have multiple pages. > scroll through the document using two fingers on touchpad. 2. Observed behavior: even small movements of fingers scroll the text so fast that it blurs, preventing following what is being scrolled, and lifting fingers up from the touchpad after scrolling makes the text jump a few lines. 3. Expected behavior: distinct movements through touchpad allow for slow scrolling which doesn’t blur the text and lifting fingers after scrolling doesn’t cause the text to jump. 4. Hardware/OS: ASUS VivoBook 15, Windows 11 Home 5. Version: 7.6.4.1 (X86_64) / LibreOffice Community Build ID: e19e193f88cd6c0525a17fb7a176ed8e6a3e2aa1 CPU threads: 12; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: pl-PL (pl_PL); UI: pl-PL Calc: threaded
*** Bug 159177 has been marked as a duplicate of this bug. ***
This is a very old bug, which is surprising considering how obvious and annoying it is. I seem to remember the same ridiculous behavior at least as far back as 2005. Part of the problem is that Libre office scrolling only ever jumps by three lines (on my system). I call that a bug. It never scrolls a single line at a time, even when using the arrow keys. It's very distracting when one is trying to read, because it's painful to track where the line you're reading went. No smoothness at all, just a jump. If you like the jumpy behavior, fine, but please give me an option to scroll a line at a time so I don't go crazy trying to follow the text. From the comments on the internet, nobody likes the jumpy behavior. That, plus Libre Writer, unlike every other application on the machine, skips way too fast when scrolling by touchpad - and there is NO adjustment in Libre. I've tried all the options suggested in various forums, but of course none of them work. As a developer I'd love to jump in and fix this, but being unfamiliar with the code I might make it worse. Please please please, if you're a Libre developer, don't add some shiny new feature. Please fix this terrible longstanding bug. Demonstrating that this problem goes back at least to 2015: https://ask.libreoffice.org/t/is-it-possible-to-adjust-the-scrolling-speed-in-all-libreoffice-apps/13172 https://www.reddit.com/r/libreoffice/comments/enf3p4/touchpad_scroll_speed/