ScrollView generates a lot of debug output

[torleifat]

Describe the bug

In C++(have not tested C#) the ScrollView seems to generate a lot of (what to me seems like) debug output like this:

    Msg:[Bridges should always configure HostProvider for WM_GETOBJECT __before__ GetAutomationHostProvider is called.] 
onecoreuap\windows\moderncore\inputv2\inputhost\inside\lifted\contentisland.cpp(3171)\Microsoft.UI.Input.dll!00007FFD5D310737: (caller: 00007FFD5ACE3BA5) ReturnHr(276) tid(e724) 80070490 Element not found.
onecoreuap\windows\moderncore\inputv2\inputhost\inside\lifted\contentisland.cpp(2092)\Microsoft.UI.Input.dll!00007FFD5D310845: (caller: 00007FFD5D310718) ReturnHr(277) tid(e724) 80070490 Element not found.
    Msg:[Bridges should always configure HostProvider for WM_GETOBJECT __before__ GetAutomationHostProvider is called.] 
onecoreuap\windows\moderncore\inputv2\inputhost\inside\lifted\contentisland.cpp(3171)\Microsoft.UI.Input.dll!00007FFD5D310737: (caller: 00007FFD5ACE3BA5) ReturnHr(278) tid(e724) 80070490 Element not found.
onecoreuap\windows\moderncore\inputv2\inputhost\inside\lifted\contentisland.cpp(2092)\Microsoft.UI.Input.dll!00007FFD5D310845: (caller: 00007FFD5D310718) ReturnHr(279) tid(e724) 80070490 Element not found.
    Msg:[Bridges should always configure HostProvider for WM_GETOBJECT __before__ GetAutomationHostProvider is called.] 
onecoreuap\windows\moderncore\inputv2\inputhost\inside\lifted\contentisland.cpp(3171)\Microsoft.UI.Input.dll!00007FFD5D310737: (caller: 00007FFD5ACE3BA5) ReturnHr(280) tid(e724) 80070490 Element not found.
onecoreuap\windows\moderncore\inputv2\inputhost\inside\lifted\contentisland.cpp(2092)\Microsoft.UI.Input.dll!00007FFD5D310845: (caller: 00007FFD5D310718) ReturnHr(281) tid(e724) 80070490 Element not found.

This happens when you scroll around in the image, either by user input or programmatically. And it will not just generate one line, but 10 to 20 lines. And as I use the output panel quite a bit to follow my own debug output it becomes annoying and easy to miss more important events.

Steps to reproduce the bug

1. Create a new WinUI C++ project
2. Remove the default fluff from MainWindow.xaml
3. Add an image to the project (I used the Cliff image from the WinUI 3 gallery app)
4. Add a scroll view to the MainWindow:

 <ScrollView Height="133" Width="200" ContentOrientation="None"
             ZoomMode="Enabled" IsTabStop="True"
             VerticalAlignment="Top" HorizontalAlignment="Left"
             HorizontalScrollMode="Auto" HorizontalScrollBarVisibility="Auto"
             VerticalScrollMode="Auto" VerticalScrollBarVisibility="Auto">
   <Image Source="ms-appx:///Assets/cliff.jpg" AutomationProperties.Name="cliff" Stretch="None" />
 </ScrollView>

Make sure it is smaller than the original image so that scrollbars will appear.

Run the application, scroll around and observe the Output panel i VS.

Expected behavior

For ScrollView not to be so talkative in the output panel.

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.5.1: 1.5.240311000

Windows version

Windows 11 (22H2): Build 22621

Additional context

Happens in both unpackaged and packaged apps.

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one. Thank you!

Closed similar issues:

• ScrollerView causes app crash in Debug configuration (#102), similarity score: 0.76

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[eduardobragaxz]

In a C# app you can see it if you enable native code debugging. I see this in my app.

[torleifat]

A related issue I had forgotten about, and perhaps should be its own issue, is that if the Image has Stretch set to None and the image is in fact larger than the ScrollView: When you scroll it will not actually render the parts of the image that was previously hidden. I had a post about it in the discussion section some time back, #8918, I ended up finding a workaround for my use case(discussed in the post). But I don't think this is intended behavior.