Improve keyboard scrolling with editors, contentInsets, and different keyboards #24589
Conversation
tj-devel709
added
platform/iOS 🍎
area-controls-entry
|
I know this was painful to fix, so thanks a lot for all the effort spent here! |
|
Thank you for your work on this! Please let me know if you need somebody to test it for you :) I am patiently waiting for the next SR that contains this PR |
|
thanks @tj-devel709 this is super helpful |
|
@ramonB1996 you can test this PR using the artifacts from the MAUI-public build. Just download the |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
Seems IOS test failing |
tj-devel709
dismissed stale reviews from mattleibow and PureWeen
via
508ad6e
tj-devel709
force-pushed
the
dev/TJ/keyboardScroll-Inset-Improvements_1
branch
from
508ad6e
to
62f48f0
Compare
… is not the keyboard
…view the opposite direction
tj-devel709
force-pushed
the
dev/TJ/keyboardScroll-Inset-Improvements_1
branch
from
62f48f0
to
ef5db99
Compare
|
Is there an ETA for this change? We are hoping on a release in the next few days or we have to decide to manually backport it into our branch. |
samhouts
added
the
fixed-in-net8.0-nightly
… keyboards (dotnet#24589) * Changes to improve keyboard scrolling with editors, contentInsets, and different keyboards * picker6 screenshot * Add entry7 screenshot test * reset test state * fix the distance between keyboard and cursor and remove null forgiving * bottomBoundary should have the TextDistanceFromBottom when the bottom is not the keyboard * FireAndForget * new entry7 screenshot * add back the distance from bottom in the insets * Allow partial scrolling one direction and then moving the next scrollview the opposite direction * Adjust insets on UITextView and other scrollviews * we dont need more inset if no keyboard intersection * add edge case where we have small editor
samhouts
added
the
fixed-in-net9.0-nightly
samhouts
added
fixed-in-9.0.0-rc.2.24503.2
fixed-in-net8.0-nightly
|
Why hasn't this been released yet? meanwhile there have been two releases without this fix (sr9.1 and sr9.2) We have multiple production releases waiting for this fix. |
|
@Toine-db as indicated by the labels, this is available in the nightlies as well as .NET 9 RC2. With .NET 9 close to being released I'm not sure if this will be backported to .NET 8 still but I'll ask around! |
Perhaps you can use a nightly version which should contain this fix. |
My apologies, I meant the releases of .Net8 and I assumed it was backported to Net8 because it was in de Net8 nightly. I tested it with the nightly build, and that works fine. But I can't release production versions for our apps with nightly or beta versions of any kind. |
|
Ah yeah! I see what you're saying sorry. Since we're so close to .NET 9, I'm not sure if there will be another "full" .NET 8 SR soon unless we really have to. So I'm afraid this will probably land in .NET 9. |
Description of Change
This PR addresses a few different but related issues regarding the user experience with the keyboard on iOS devices.
The first issue is that currently, keyboard scrolling logic only applies if a focused entry/editor’s cursor is obstructed by the keyboard. Not only does the keyboard scroll, but the contentInsets are adjusted on the scrolling page/control allowing us to scroll to the top and bottom even with the keyboard showing. However, if we interact with something above the keyboard, we still need to adjust the contentInsets to adjust so that we can scroll and reach the bottom of the content now covered by the showing keyboard. This PR addresses this issue.
The second issue is when pickers are focused, the cursor has a size of zero so when we click on a picker, the screen scrolls to where only the top of the picker is showing. This PR makes it so the whole picker is now visible.
The third issue this PR addresses is when the keyboard is already showing and we focus a different control that invokes a different type of keyboard, we were not calculating if we need to scroll again. This issue shows up when things like a picker are focused and then an entry with a larger numeric keyboard is focused after.
The final issue this PR addresses is keeping the cursor above the keyboard when we add new lines to an editor. This is done by changing the contentInset on editors (whether the editor is scrolling or not) essentially moving the bottom of the editor above the keyboard. As a result, we can have a much better experience and see the cursor as we are typing.
This PR is a continuation of #21807 and #21932 and a special thanks to @albyrock87 for seeing that keeping the editor’s cursor above the keyboard was possible and for pointing out the correct way to find the rects respective to the windows which were both crucial to this PR!
KeyboardScrollingDemo.mp4
Small inconsistency where the cursor may stay a little higher above the keyboard than usual in an edge case: #24635.
Issues Fixed
Fixes #19214
Fixes #24496
Fixes #20631
Fixes #22715