Bug 442060 - Mac OS Trackpad scroll buggy
Summary: Mac OS Trackpad scroll buggy
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: application (show other bugs)
Version: 21.08.1
Platform: macOS (DMG) macOS
: NOR minor
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 450678 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-09-06 01:08 UTC by axcelia
Modified: 2022-02-24 08:46 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Screen recording of the issue. (539.64 KB, video/mp4)
2021-09-06 01:08 UTC, axcelia
Details
repro #2 log (2.95 MB, text/plain)
2021-09-21 11:01 UTC, Adrian Damian
Details
repro #2 screen recording (2.61 MB, video/x-m4v)
2021-09-21 11:12 UTC, Adrian Damian
Details
repro #3 timeline full (6.50 KB, text/plain)
2021-09-28 13:36 UTC, Adrian Damian
Details
repro #3 log (846.00 KB, text/plain)
2021-09-28 13:44 UTC, Adrian Damian
Details

Note You need to log in before you can comment on or make changes to this bug.
Description axcelia 2021-09-06 01:08:30 UTC
Created attachment 141322 [details]
Screen recording of the issue.

SUMMARY
When you try to scroll using the trackpad on a MacBook Pro it responds erraticaly. Sometimes it tries to scroll back up when you are scrolling down and jumps about or tries to scroll back down when you are scrolling up and jumps around. It's ok if you hover over the overview and scroll, it only seems to be an issue in the main editor screen. 


STEPS TO REPRODUCE
1. Open any file that requires you to scroll
2. Try and scroll up and down a few times using the inbuilt trackpad
3. 

OBSERVED RESULT
Scrolling is erratic and jumps about.


EXPECTED RESULT
Smooth scrolling that goes in the correct direction.

SOFTWARE/OS VERSIONS

macOS: OS X 10.15.7


ADDITIONAL INFORMATION
I've attached a screen recording of the issue. I'm trying to scroll back up in the video but it keeps flicking back down until suddenly overshooting right to the very top.
Comment 1 Adrian Damian 2021-09-21 11:01:41 UTC
Created attachment 141761 [details]
repro #2 log

Generated with:

QT_LOGGING_RULES="*=true" /Applications/kate\ 2.app/Contents/MacOS/kate CHANGES.rst 2>&1 | ts -s '%.S' > kate.log

and then scrolling for about 10 seconds.
Comment 2 Adrian Damian 2021-09-21 11:12:20 UTC
Created attachment 141762 [details]
repro #2 screen recording

Kate on the left, Thonny on the right (for comparison).

In each of them, I scroll down 3 times and then up 3 times.
Comment 3 Adrian Damian 2021-09-21 11:33:27 UTC
I am able to reproduce this as well.

Please let me know if you need additional data (I don't know about Qt / KDE to debug this further).

IMHO, the importance should be higher; at least for me, this makes using Kate almost impossible.

Thank you!

---

VERSIONS

macOS 10.15.7
Kate 21.08.1 (from kate-21.08.1-1348-macos-64-clang.dmg)
KDE Frameworks 5.86.0
Qt 5.15.2 (built against 5.15.2)

The only enabled plugins were Search & Replace and Text Filter.

---

Attached "repro #2 log" and "repro #2 screen recording"; the log was generated by scrolling up and down a few times in a Kate window started with:

QT_LOGGING_RULES="*=true" /Applications/kate\ 2.app/Contents/MacOS/kate CHANGES.rst 2>&1 | ts -s '%.S' > kate.log

---

A version from ~March 2021 did not have this issue; unfortunately I replaced the installation and don't know the exact version.

Trying to get that back, I managed to get a 21.04.3 version to build successfully with Craft; this version still has the scrolling issue:

Kate 21.04.3
KDE Frameworks 5.83.0
Qt 5.15.2 (built against 5.15.2)

I couldn't get a successful build with versions earlier than this.

---

This Reddit thread seems to describe the same issue: https://www.reddit.com/r/kde/comments/p8byi9/kate_scrolling_problem_on_mac/
Comment 4 axcelia 2021-09-22 17:58:49 UTC
I just wanted to add something I thought was worth mentioning since I've been fighting with this issue for a week or so.

When I'm seeing the problem it's almost like it's trying to imitate the default natural scroll on the mac. I have natural scroll switched off because I'm used to scrolling the other way but I was wondering if somewhere it's assuming Natural scroll should be switched on so it's scrolling the wrong way initially.
Comment 5 Adrian Damian 2021-09-28 13:36:35 UTC
Created attachment 141991 [details]
repro #3 timeline full
Comment 6 Adrian Damian 2021-09-28 13:44:45 UTC
Created attachment 141992 [details]
repro #3 log

Based on some log combing, I reached this hypothesis:

The scroll stutter happens because "NSEvent: type=ScrollWheel" events either stop being emmited or stop being processed, and a second-long gesture is started and keeps being updated as I keep moving my fingers on the trackpad a second time.

I can't tell if the gesture starts because ScrollWheel NSEvents stop happening, OR if the gesture being started prevents the ScrollWheel events in the first place.

Next things I plan to do to narrow this further (any suggestions are *highly* appreciated, since I'm really out of my depth here):

* disable gestures (if possible), and see if the stutter still happens
* search for Qt bugs having to do with gestures and scrolling / mouse events

---

I obtained the log by starting Kate at the end of a file that's ~2k lines long, and scrolling up a few times (details on the log below).

Timeline (seconds since app start, matching the log output):

* ~6 start scrolling
* ~6.8 scroll starts happening on screen

* 6.29 .. 8.58 (repeating every ~.01s, interleaved in various ways)
  
      QGestureManager:Recognizer: ignored the event:
      Sending NSEvent: type=ScrollWheel
      Qt::ScrollUpdate
      Sending NSEvent: type=Gesture
      touchesMovedWithEvent
      
      Qt::ScrollMomentum

* 8.58 these stop appearing as frequently

      Qt::ScrollUpdate
      Sending NSEvent: type=ScrollWheel
      Qt::ScrollMomentum
      
  type=Gesture, touchesMovedWithEvent and "ignored the event" keep appearing

* ~8.6 scroll stutters visibly (it's likely at this point I've lifted my fingers off the trackpad and and put them down again to start scrolling a second time)
* ~10.1 scroll stutters visibly (same as above)

* 10.41 "QGestureManager:Recognizer: maybe gesture"

      touchesEndedWithEvent
      QGestureManager:Recognizer: not gesture:
      touchesBeganWithEvent
      QGestureManager:Recognizer: maybe gesture:
      QGestureManager::filterEventThroughContexts: 
      started gesture was delivered and accepted by KateViewInternal(0x7f85d9be3660)
    
* 10.46 (repeated until 13.07) "QGestureManager:Recognizer: gesture triggered"
    
      QGestureManager::deliverEvents: sending to KateViewInternal(0x7f85d9be3660) gestures:
      touchesMovedWithEvent
      QGestureManager:Recognizer: gesture triggered:
      QGestureManager::filterEventThroughContexts: 
          triggered: QSet(Custom gesture(state=GestureUpdated,hotSpot=...,type=Qt::GestureType(258)))
      QGestureManager::deliverEvents: 
      
      (every other 5-10 of the above)
      QGestureManager: we were asked to consume the event:
      
      (very few; ~8 during 10, 2 during 11, 1 during 12)
      Qt::ScrollUpdate
    
* ~11.1 scroll stops entirely

* 13:07
    
      (first time after 10.41)
      Sending NSEvent: type=ScrollWheel

      Qt::ScrollEnd
      touchesEndedWithEvent

--- 
      
"repro #3 timeline full" has a more complete timeline.

"repro #3 log" has the full log, obtained with:

QT_LOGGING_RULES="*=true" \
/Applications/kate\ 2.app/Contents/MacOS/kate ~/tomatoes.md 2>&1 \
| ts -s '%.S' \
| grep -Ev \
    -e qt.widgets.painting \
    -e qt.qpa.backingstore \
    -e kf.texteditor \
    -e kf.sonnet. \
| tee ~/Desktop/repro-3.log

The Kate used was kate-21.08.1-1354-macos-64-clang.dmg (KDE Frameworks 5.86.0,
Qt 5.15.2 (built against 5.15.2)).
Comment 7 Adrian Damian 2021-10-05 12:30:37 UTC
OK, I think I managed to narrow down the issue to these two commits. Reverting them makes the scroll stutter / stop (while still two-finger scrolling on the trackpad) go away.

https://invent.kde.org/frameworks/ktexteditor/-/commit/8f8be67ccf5b151d4c6cc570229fe4fbe28e76b3 "Add basic touchscreen support"
https://invent.kde.org/frameworks/ktexteditor/-/commit/aa757c80e6ce8efee288c58154998d4e8e0f0dde "Use Okular's QScroller settings"

I used the latest versions of libraries:

kde/applications/kate                   : 21.08.1
kde/frameworks/tier3/ktexteditor        : 5.86.0

I don't really know how to fix this, other than reverting the two commits (but that would remove touchscreen support). Is reverting OK?

For now I'll keep using my own build.

---

For anyone that's affected by this, here's how to make your own build:

* Install Craft: https://community.kde.org/Guidelines_and_HOWTOs/Build_from_source/Mac#Installation_using_Craft (commands below assume the default ~/CraftRoot path was used).

* AFAICT, this "installs" the two packages (kate uses ktexteditor) in a way that allows the sources to be edited (at ~/CraftRoot/build/$full_package_name/work/$package-$version).

    craft -i --no-cache kate ktexteditor

* Remove the lines added in the two commits above from these files:

    ~/CraftRoot/build/kde/frameworks/tier3/ktexteditor/work/ktexteditor-5.86.0/src/view/kateviewinternal.cpp
    ~/CraftRoot/build/kde/frameworks/tier3/ktexteditor/work/ktexteditor-5.86.0/src/view/kateviewinternal.h

   The versions may vary, you can go to the directory that contains src/ by doing "cs ktexteditor".

* Compile the changes and create an installer:

    craft --compile --install --qmerge ktexteditor kate && craft --package kate

  The path to a .dmg should be output at the end; should be something like:

    ~/CraftRoot/tmp/kate-21.08.1-macos-64-clang.dmg
Comment 8 Christoph Cullmann 2021-10-05 13:19:58 UTC
Just reverting won't be a good idea, that will break the stuff we added this commits for.

As one seems to be taken from Okular, does Okular have the same issues?
Comment 9 Adrian Damian 2021-10-06 05:51:36 UTC
I currently can't test Okular, since I can't get it to build:

* I've tried building it twice, but it fails during `craft package` with "don't know how to handle otool -L output", and I'm not sure how to fix this.
  * Running ./build/kde/applications/okular/archive/Applications/KDE/okular.app/Contents/MacOS/okular fails too (no window shows), likely because `package` didn't finish (this works for Kate after `package` finishes successfully).
* The Jenkins builds seem to be failing as well, but with a different(?) error: https://binary-factory.kde.org/view/MacOS/job/Okular_Release_macos/

If there's a way to run stuff from /build/kde/applications/okular/... on MacOS without `package` doing its thing, please let me know (I've struggled with finding a LD_LIBRARY_PATH equivalent on MacOS in the past, and that's what `package` seems to be doing).
Comment 10 Christoph Cullmann 2021-10-07 19:37:02 UTC
I think some dependency is missing, as e.g. libKF5Pty is not found (at least if I read the fail right).

I could take a look.
Comment 11 Christoph Cullmann 2021-10-07 19:38:59 UTC
Git commit 005c41914edd500bd86b7365af456eec1f7016da by Christoph Cullmann.
Committed on 07/10/2021 at 19:38.
Pushed by cullmann into branch 'master'.

add kpty, macOS compiles fails because it is missing

M  +2    -1    kde/applications/okular/okular.py

https://invent.kde.org/packaging/craft-blueprints-kde/commit/005c41914edd500bd86b7365af456eec1f7016da
Comment 12 Christoph Cullmann 2021-10-07 19:50:24 UTC
macOS Okular should build again:

https://binary-factory.kde.org/view/MacOS/job/Okular_Release_macos/758/console
Comment 13 Adrian Damian 2021-10-08 11:37:12 UTC
Thank you, Christoph!

Unfortunately, the successful build of Okular (okular-21.08.2-758-macos-64-clang.dmg) fails to start on my Mac; the icon appears in the dock, but then nothing happens (there's no output on the terminal).

I've noticed this happens for Kate too when running:

~/CraftRoot/build/kde/applications/kate/image-RelWithDebInfo-21.08.1/Applications/KDE/kate.app/Contents/MacOS/kate (hangs)

but not when running:

~/CraftRoot/build/kde/applications/kate/archive/Applications/KDE/kate.app/Contents/MacOS/kate (starts OK, likely generated by "craft --package")

Since "craft --package" seems to be fixing the RPATH of binaries, I suspect the Okular packaging script isn't fixing all of them (this is just a guess, though).
Comment 14 Waqar Ahmed 2022-02-22 19:49:57 UTC
*** Bug 450678 has been marked as a duplicate of this bug. ***
Comment 15 Bug Janitor Service 2022-02-23 21:49:01 UTC
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/ktexteditor/-/merge_requests/295
Comment 16 Georg Gadinger 2022-02-24 08:46:16 UTC
Git commit 45258cb05e3af44b6c2e2e214f46d4f52cae4e88 by Georg Gadinger.
Committed on 23/02/2022 at 21:45.
Pushed by cullmann into branch 'master'.

view: fix buggy scrolling on macOS

On macOS the trackpad also emits touch events which are sometimes
picked up by the flick gesture recogniser registered by QScroller;
this results in some odd scrolling behaviour as described in bug
442060. Therefore it's better to not let the QScroller register it
on that platform.

M  +6    -0    src/view/kateviewinternal.cpp

https://invent.kde.org/frameworks/ktexteditor/commit/45258cb05e3af44b6c2e2e214f46d4f52cae4e88