Before you all think I am stark raving mad, it appears that it is actually possible to create XAML constructions that confuse the UWP renderer to such an extent that, although it moves the user interface upwards as it should, it does not always move it up far enough. This can be observed in the video below, as well as the fact that it is fixable.

A user observed this on my app Map Mania (it has been fixed since). I have only been able to repro this on Windows 10 mobile. Apparently it has something to do with going rampant on adaptive triggers, and another key part is the use of a bottom app bar.

The XAML is a simplified version of what I used for the post about a CompositeTrigger-enabled AdaptiveTrigger. Basically, I use a simple ViewModel and VisualStateGroup with some Triggers to change what I see on the screen. The XAML is not too complicated:

<Grid >
 <Grid.RowDefinitions>
 <RowDefinition Height="Auto"></RowDefinition>
 <RowDefinition Height="*"></RowDefinition>
 </Grid.RowDefinitions>
 <controls:PageHeader Text="Fix" FontSize="30" VisualStateNarrowMinWidth="0" 
 VisualStateNormalMinWidth="700"></controls:PageHeader >
 <Grid Grid.Row="1" Margin="12" x:Name="TopGrid">
 <Grid.ColumnDefinitions>
 <ColumnDefinition Width="*"></ColumnDefinition>
 </Grid.ColumnDefinitions>
 <Grid>
 <Grid.RowDefinitions>
 <RowDefinition Height="60"></RowDefinition>
 <RowDefinition Height="*"></RowDefinition>
 <RowDefinition Height="Auto"></RowDefinition>
 </Grid.RowDefinitions>

 <Grid Margin="0,6,0,6" x:Name="NarrowMenu" >
 <Grid.RowDefinitions>
 <RowDefinition Height="Auto"></RowDefinition>
 <RowDefinition Height="Auto"></RowDefinition>
 </Grid.RowDefinitions>
 <Grid.ColumnDefinitions>
 <ColumnDefinition Width="Auto"></ColumnDefinition>
 <ColumnDefinition Width="Auto"></ColumnDefinition>
 </Grid.ColumnDefinitions>
 <TextBlock Text="Green" Grid.Row="0" FontSize="20"
 Margin="0,0,6,0" Tapped="{x:Bind ViewModel.ToggleDisplay}" >
 </TextBlock>

 <TextBlock Text="Red" Grid.Row="0" Grid.Column="1" FontSize="20"
 Margin="6,0,0,0" Tapped="{x:Bind ViewModel.ToggleDisplay}">
 </TextBlock>
 <Grid Height="2" Background="White" Grid.Row="1" Grid.Column="0" Margin="0,0,6,0" 
 x:Name="GreenUnderline"/>
 <Grid Height="2" Background="White" Grid.Row="1" Grid.Column="1" Margin="6,0,0,0" 
 x:Name="RedUnderline"/>
 </Grid>

 <Grid Background="Green" Grid.Row="1" x:Name="GreenArea"></Grid>
 <Grid Background="Red" Grid.Row="1" x:Name="WideRedArea"></Grid>

      <StackPanel Grid.Row="2" Orientation="Vertical" HorizontalAlignment="Stretch" 
         VerticalAlignment="Bottom" >
        <TextBlock  Text="Some label" x:Uid="MapName"  Margin="0,0,0,6"/>
        <TextBox TextWrapping="NoWrap"/>
      </StackPanel>
 </Grid>
 </Grid>
</Grid>

This stuff is based on Template10, but the actual usage is very limited. First, we have some heading, then the menu, then the two areas (green and red) that are used to fill the middle of the screen—it stands in for actual content. Then, all the way below in red and bold, the StackPanel that has some problems as displayed in the video. When you click on the menu text (“Red” and “Green”) a command in the view model is called that flips a property “TabDisplay”. This triggers the VisualStateManager.

The VisualStateManager is actually pretty simple:

<VisualStateManager.VisualStateGroups>
 <VisualStateGroup x:Name="WindowStates" >
 <VisualState x:Name="NarrowState_Red">
 <VisualState.StateTriggers>
 <StateTrigger IsActive="{x:Bind ViewModel.TabDisplay, Mode=OneWay}"/>
 </VisualState.StateTriggers>
 <VisualState.Setters>
 <Setter Target="WideRedArea.Visibility" Value="Visible"></Setter>

 <Setter Target="GreenUnderline.Visibility" Value="Collapsed"></Setter>
 </VisualState.Setters>
 </VisualState>

 <VisualState x:Name="NarrowState_Green">
 <VisualState.StateTriggers>
 <StateTrigger 
 IsActive=
 "{x:Bind ViewModel.TabDisplay, Mode=OneWay,Converter={StaticResource BoolInvertConverter}}"/>
 </VisualState.StateTriggers>
 <VisualState.Setters>
 <Setter Target="WideRedArea.Visibility" Value="Collapsed"></Setter>
 <Setter Target="RedUnderline.Visibility" Value="Collapsed"></Setter>
 </VisualState.Setters>
 </VisualState>

 </VisualStateGroup>
</VisualStateManager.VisualStateGroups

So far, so good but when you use a construction like this, and you put anything below it, your might run into issues as I described.Unless you add a little something to the StackPanel:

<StackPanel Grid.Row="2" Orientation="Vertical" HorizontalAlignment="Stretch"
 VerticalAlignment="Bottom" >
  <interactivity:Interaction.Behaviors>
    <behaviors:KeepAboveInputPaneBehavior/>
  </interactivity:Interaction.Behaviors>
 <TextBlock Text="Some label" x:Uid="MapName" Margin="0,0,0,6"/>
 <TextBox TextWrapping="NoWrap"/>
</StackPanel

And people who know me won’t be surprised is it actually a behavior again.

using Windows.UI.ViewManagement;
using Windows.UI.Xaml;
using Microsoft.Xaml.Interactivity;

namespace WpWinNl.Behaviors
{
 public class KeepAboveInputPaneBehavior : Behavior<FrameworkElement>
 {
 private Thickness _originalMargin;

 protected override void OnAttached()
 {
 base.OnAttached();
 AssociatedObject.Loaded += AssociatedObjectLoaded;
 _originalMargin = AssociatedObject.Margin;
 }

 private void AssociatedObjectLoaded(object sender, RoutedEventArgs e)
 {
 AssociatedObject.Loaded -= AssociatedObjectLoaded;
 InputPane.GetForCurrentView().Hiding += InputPaneHiding;
 InputPane.GetForCurrentView().Showing += InputPaneShowing;
 }

 protected override void OnDetaching()
 {
 InputPane.GetForCurrentView().Hiding -= InputPaneHiding;
 InputPane.GetForCurrentView().Showing -= InputPaneShowing;
 }

 private void InputPaneShowing(InputPane sender, InputPaneVisibilityEventArgs args)
 {
 AssociatedObject.Margin = 
 new Thickness(_originalMargin.Left, _originalMargin.Top, 
 _originalMargin.Right, _originalMargin.Bottom + args.OccludedRect.Height);
 }

 private void InputPaneHiding(InputPane sender, InputPaneVisibilityEventArgs args)
 {
 AssociatedObject.Margin = _originalMargin;
 }
 }
}

When the attached object is loaded, it’s original margins are recorded. When the input pane is showing, the height of the ‘OcculedRect’ is added to it, moving the attached object op to exactly above the input bar.

This is possibly a bug, or the SDK team just never imagined people doing odd things with the Visual State Manager – “A fool may ask more questions in an hour than a wise man can answer in seven years”, right ;). Whatever, I like I tell people you can moan about things like this or cry foul at Microsoft, but I find it much more fun to try and fix them. QED.

A sample solution, with the behavior, can be found here.