Replies: 2 comments
|
Same, here. It seems always scroll to top instead of the inputs now. |
0 replies
|
Hey, it seems to be an issue rather than a discussion, so I'm moving it into issues: #1394 Feel free to post more info there, I'll close this discussion! |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
On initial input focus there's some inaccuracy in the scrolling offset, which corrects on second focus attempt, but every time you focus a different input, it's doesn't go all the way as expected. Especially noticeable for multiline inputs.
When there's not enough space at the bottom for scrolling, well, it doesn't scroll when keyboard appears. That means I always need to add at least a keyboard size spacer at the bottom, fixed, since the point of the new scrollview that we don't resize the containers. I thought the new technique is that it adds some special padding internally that let content clip and extend the scrollable limits temporarily, so I don't need to do layout manipulations.
https://github.com/user-attachments/assets/0d6cad3f-5043-4977-8542-cabba62a3845
repo with apk included.
https://github.com/grego5/rnkbctrldemo
Also I haven't noticed extraKeyboardSpace makes any difference.
I wanted to upgrade this pattern but seems too early. (The animated view smoothes the layout shift transitions).
All reactions