TwoPaneView layout bug when touch keyboard is visible

Describe the bug There are gap between TwoPaneView content and touch keyboard. The height of the gap is approximately equal to the height of the touch keyboard. Seems that it is caused by setting ScrollViewer.ReduceViewportForCoreInputViewOcclusions = true inside TwoPaneView, as disabling this property via VS Live Property Explorer fixes the problem.

Steps to reproduce the bug

Steps to reproduce the behavior:

1. VS2019 > Create New Project > Blank C++/CX Application, Target 19041, MinTarget 17763, in MainPage.xaml add

    <TwoPaneView>
        <TwoPaneView.Pane1>
            <Rectangle Fill="Blue"/>
        </TwoPaneView.Pane1>
        <TwoPaneView.Pane2>
            <Rectangle Fill="Green"/>
        </TwoPaneView.Pane2>
    </TwoPaneView>

1. Run with maximized window, show touch keyboard (TaskBar > Show Touch Keyboard Button may help). Also could be repeated with non-maximized smaller window placed into the area that would be occluded by touch keyboard. In this case it could be seen that the window is moved up (by the OS?) to avoid occluding, and yet TwoPaneView content is unnecessarily moved inside the window.

Expected behavior Content of TwoPaneView should move so it would not be occluded by touch keyboard. Instead, it is moved twice as far, and there are tall gap between content and touch keyboard.

Screenshots

Version Info Could be repeated with TwoPaneView from both Microsoft.UI.Xaml 2.6.1, 2.5.0 and Windows.UI.Xaml. App Target 19041, MinTarget 17763. Windows 10 21H1 19043, could be repeated on both Tablets and Desktop (TaskBar > Show Touch Keyboard Button) form factors

NuGet package version:

Windows app type:

UWP	Win32
Yes

Windows version	Saw the problem?
Insider Build (xxxxx)
21H1 Update (19043)	Yes
October 2020 Update (19042)
May 2020 Update (19041)
November 2019 Update (18363)
May 2019 Update (18362)
October 2018 Update (17763)
April 2018 Update (17134)
Fall Creators Update (16299)
Creators Update (15063)

Device form factor	Saw the problem?
Desktop	Yes
Xbox
Surface Hub
IoT

Additional context

[eugenegff]

BTW, according to documentation for ScrollViewer.ReduceViewportForCoreInputViewOcclusions property

This property defaults to false, and it’s typically not necessary for you to set it in your app. XAML maintains a ScrollViewer internally with this feature enabled, and your window content is displayed in this ScrollViewer. That is, Window.Current.Content is automatically parented to a ScrollViewer that has this feature enabled.

and it is NOT set for RootScrollViewer on Win10.0.19043. Given the fact that OS seems to move window to avoid occlusion by touch keyboard - this property is redundant, causes layout bug, and should probably be set only for old OSes that does not move window.

If this were true we would see this issue without the use of two pane view, correct? Or are you referring to a scrollviewer within the two pane view template?

I mean that property intended for RootScrollViewer is NOT set on RootScrollViewer now, and RootScrollViewer does not show buggy layout. But this property is set for both scrollviewers within two pane view template - and TwoPaneView shows buggy layout.

I suspect, that at some version Windows OS starts to adjust position and size of window to avoid occlusion by touch keyboard, therefore making this property redundant and obsolete, and for RootScrollViewer it is probably set conditionally, only for Windows versions that does not adjust window position and/or size. But for scroll viewers within TwoPaneView it is set unconditionally, causing problems.

[eugenegff]

BTW, according to documentation for ScrollViewer.ReduceViewportForCoreInputViewOcclusions property

This property defaults to false, and it’s typically not necessary for you to set it in your app. XAML maintains a ScrollViewer internally with this feature enabled, and your window content is displayed in this ScrollViewer. That is, Window.Current.Content is automatically parented to a ScrollViewer that has this feature enabled.

and it is NOT set for RootScrollViewer on Win10.0.19043. Given the fact that OS seems to move window to avoid occlusion by touch keyboard - this property is redundant, causes layout bug, and should probably be set only for old OSes that does not move window.