CoreInputView.OcclusionsChanged not providing occlusions

[buhcsa]

Describe the bug

Unlike in version 1.5.x of Microsoft.WindowsAppSDK, the CoreInputView.OcclusionsChanged event in version 1.6.x does not provide occlusions in the argument CoreInputViewOcclusionsChangedEventArgs

Steps to reproduce the bug

Create a new WinUI3 desktop app project, named "WinUI3App1".
Replace:

• MainWindow.xaml

<?xml version="1.0" encoding="utf-8"?>
<Window x:Class="WinUI3App1.MainWindow" xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
    <TextBox x:Name="myTextBox" HorizontalAlignment="Center" VerticalAlignment="Center"/>
</Window>

• MainWindow.cs

using Microsoft.UI.Xaml;
using System.Diagnostics;
using Windows.UI.ViewManagement.Core;

namespace WinUI3App1;

public sealed partial class MainWindow : Window
{
    readonly CoreInputView inputView;
    public MainWindow()
    {
        InitializeComponent();
        (inputView = CoreInputView.GetForCurrentView()).OcclusionsChanged += (s, e) =>
            Debug.WriteLine($"Occlusions.Count={e.Occlusions.Count}");
        myTextBox.GettingFocus += (s, e) =>
            inputView.TryShow(CoreInputViewKind.Keyboard);
        myTextBox.LosingFocus += (s, e) =>
            inputView.TryHide();
    }
}

Use a high screen resolution (e.g. 1920 x 1200) and run the app in debug mode.
If the text field is focused, the input pane is shown and the debug output “Occlusions.Count=0” is generated due to the occlusion by the input pane. No occlusions are provided.

Expected behavior

The CoreInputView.OcclusionsChanged event provides occlusions in the CoreInputViewOcclusionsChangedEventArgs argument, if applicable.
In the example, if the text field is focused, the debug output “Occlusions.Count=1” is generated due to the occlusion by the input pane.

Screenshots

No response

NuGet package version

Windows App SDK 1.6.3: 1.6.241114003

Packaging type

Unpackaged

Windows version

Windows 11 version 22H2 (22621, 2022 Update)

IDE

Visual Studio 2022

Additional context

WinUI3App1.zip

[RDMacLachlan]

This is a UWP API only.

[buhcsa]

This is a UWP API only.

Sorry, but it worked fine in WinUI3 desktop app / WinRT, not UWP, with version 1.5.x of Microsoft.WindowsAppSDK. So it can't be a UWP API only.
See:

• https://learn.microsoft.com/en-us/uwp/api/windows.ui.viewmanagement.core.coreinputview.occlusionschanged?view=winrt-26100
• https://github.com/MicrosoftDocs/winrt-api/blob/docs/windows.ui.viewmanagement.core/coreinputview_occlusionschanged.md

Just use version 1.5.x of the Microsoft.WindowsAppSDK in the specified example project.
Please review the issue again. Thx.

[DarranRowe]

@RDMacLachlan

According to Windows Runtime APIs not supported in desktop apps, under the "Classes with an XxxForCurrentView method" header, there is a note that states:

"CoreInputView.GetForCurrentView is supported in desktop apps, and it can be used even without a CoreWindow. You can use that method to retrieve a CoreInputView object on any thread; and if that thread has a foreground window, then that object will produce events."

So this is supported in any destkop applications according to official documentation.

--Edit--

I'll add this in a little edit, but it is something that should be mentioned.

@buhcsa

@RDMacLachlan is correct here in that this was not expected to work. XxxForCurrentView has an implicit dependency on the ApplicationView class, and this isn't available in desktop applications. In this case, you were lucky that CoreInputView.GetForCurrentView itself was explicitly updated so that it was able to work in desktop applications. You should not expect this to work for other XxxForCurrentView functions.

As a side note, observing that something works doesn't provide evidence that it was meant to work. Concepts such as undefined behaviour, undocumented behaviour and implementation defined behaviour exist for a reason. Documentation is the key and if something works but you can't find any documentation stating that it is expected to work, then you really should think long and hard about whether you want to rely on this behaviour. I acknowledge that this was a little lectury, but I think this is a lesson worth considering.