Re-implement onWheel to fix inverted scrolling#1241
Re-implement onWheel to fix inverted scrolling#1241danalloway wants to merge 4 commits intonecolas:masterfrom danalloway:master
Conversation
|
testing this a bit more and it appears to have issues on Windows and Android, will update if I find a solution |
|
there are some cases where the corrected inverted scrolling jumps backwards as you scroll (can easily reproduce in the Brave browser) |
|
|
||
| scrollNode[direction] += delta | ||
|
|
||
| e.preventDefault(); |
There was a problem hiding this comment.
do we need this preventDefault here?
There was a problem hiding this comment.
ok, it looks like we do, as it breaks the scrolling in Chrome without it
|
ok, everything works properly on Windows across Brave, Firefox, Edge and Chrome now. |
Brave on Windows has a jump scroll, delaying the scroll adjustment my a tick fixes the issue without introducing anything noticeable across other browsers / platforms
prefer delta over wheelDelta the values they report are not the same (my mistake) so correct my previous commit
|
broken again on latest version of chrome going to close this PR for now, this isn't the way to solve it |
|
Thanks for looking into this. I'll give this some thought as it might be something we can solve at a lower level in the future |
|
you're welcome, and when that time comes let me know how I can help, even if it's just testing or vetting an idea |
|
Hey y'all, attempting to build a chat web app and running into this same problem with the inverted FlatList. is there a recommended way to workaround the scrollwheel for now, or was it not really solved? |
Beginning with this issue #995 and then this pull request #1137 with it's review, this is my attempt at a fix for inverted scrolling direction.
The original pull request #1137 did a few things differently and did not work properly on Firefox.
This PR:
deltaModeof1which gives you the number of lines, not pixels, in thedeltaYvalue of theonWheelevent. This results in the inverted scroll only scrolling a few pixels at a time.onWheelprop that is passed to the underlying ScrollView to listen to the wheel event instead of attaching an additional one. This eliminates the need to attach and detach listeners.onWheelevent to any child lists as well as forwards theonWheelprop on just like how it does in_onScroll(do we want to do this, is this right?)How I'm figuring out the number of pixels in a line is interesting, it only applies to events that have their
deltaModeset to 1 though. I question if we even need this? is just setting it do the default enough for a proper scroll experience?