[iOS] Apply contentInsets for any entry/editor in a scrollview

[tj-devel709]

Description of Change

This PR enhances the ability for scrolling up and down a scrollview when the keyboard is up. Previously, this PR worked to adjust the insets but only took effect when other keyboard scrolling logic was enacted - when you focus on something that would be covered by the keyboard. This PR extends this behavior so clicking an editor/entry above where the keyboard will come will still allow you to scroll to the top and bottom of the scrollview with the keyboard present.

Essentially, this PR is moving the content inset logic to its own method and then passing a flag to try to apply the content inset even when we do not need to scroll for the keyboard.

ContentInsetsDemoPR.mov

Issues Fixed

Fixes #19214

[albyrock87]

This variable appears to be not used (besides being set once).

[albyrock87]

Wait, now I see what you wanted to achieve, there's probably a mistake on line 671, it should be:

if (TopViewBeginOrigin != InvalidPoint)
{
    movedContainerDistance = StartingContainerViewFrame!.Value.Y - ContainerView.Frame.Y;
}

and then below

var bottomInset = keyboardIntersect.Height - movedContainerDistance;

[tj-devel709]

Great catch here, looking through the commit history, I think I was using the movedContainerDistance while working on it but meant to remove it. It doesn't seem to be needed since it is currently working without actually using the variable

[albyrock87]

I think this is actually needed, but unfortunately I don't remember the use case for this.
I will add a comment if anything comes to my mind. Thanks.

[albyrock87]

@tj-devel709 I apologize, I deleted my previous comment as it was incorrect.
So if you add a Padding to the ContentPage you'll realize this doesn't work properly.

To make this work we have to get the position of the frame in the page through the parent, and only then get the position in the window.

var frameInContainer = ContainerView!.ConvertRectFromView(scrolledView.Frame, scrolledView.Superview);
var frameInWindow = ContainerView!.ConvertRectToView(frameInContainer, null);

I've tried this and apparently it works fine in every situation.

Edit: potentially there's a way to do this using Bounds and window but I haven't had time to check it

[tj-devel709]

Can you elaborate more on this one? I am not opposed to changing, but don't fully follow the logic.

I am using the following xaml to test adding different padding and margins. I think I recall something not working properly in the past with padding or margin, but the scenarios I am trying seem to be working correctly with the existing code on the PR.
https://gist.github.com/tj-devel709/41155daf1fb91695852ac48f14886eed

[albyrock87]

@tj-devel709 I cannot reproduce anymore and I'm not sure why.
What I know is that at some point I was testing this code, and instead of getting an Y coordinate which included the padding I added to the ContentPage, I was getting an Y coordinate which was not considering that padding.
So I'm good for now, anyway I would add some UI test which include a padding at page level, just to be sure that it is always accounted in measurements.

[albyrock87]

I also commented about this on my PR, but for the record let me add also here that there's a strange whitespace appearing at the top with this sequence of actions in the following layout Auto,*,Auto where Editor is in the *.

[jsuarezruiz]

[tj-devel709]

Moving to draft until ready for review!

[tj-devel709]

Closing this one in favor of #24589