ViewportBehavior logging events only fire once

[XAML-Knight]

Describe the bug

When interacting with the ViewportBehavior Sample page, notice that the events that log the user interaction (i.e., element is scrolled into view, then scrolled out, then back in, etc.) only get logged once to the Log display. After the visual/UI element is scrolling into view, and then fully in view, no more logging occurs, regardless of user interaction.

• Is this bug a regression in the toolkit? If so, what toolkit version did you last see it work:

Steps to Reproduce

• Can this be reproduced in the Sample App? (Either in a sample as-is or with new XAML pasted in the editor.) If so, please provide custom XAML or steps to reproduce. If not, let us know why it can't be reproduced (e.g. more complex setup, environment, dependencies, etc...)

Steps to reproduce the behavior:

1. Run Sample App
2. Go to ViewportBehavior
3. Scroll down to get the visual element to be Entering viewport in the Logs display section
4. Keep scrolling down to get the visual element to be fully Entered viewport in the Logs display section
5. Continue to scroll up or down, into or completely out of view, and notice that nothing else ever gets logged in the Logs display section

Expected behavior

Continuous logging should be happening in the Logs display section, as relevant user interaction continues to happen.

Screenshots

Environment

Device form factor:

• Desktop
• Xbox
• Surface Hub
• IoT

Visual Studio version:

• 2017 (15.{minor_version})
• 2019 (16.10.3), Debug, x64
• 2022 (17.{minor_version})

Additional context

[ghost]

Hello XAML-Knight, thank you for opening an issue with us!

I have automatically added a "needs triage" label to help get things started. Our team will analyze and investigate the issue, and escalate it to the relevant team if possible. Other community members may also look into the issue and provide feedback 🙌

[michael-hawker]

@XAML-Knight I think there's a property about preventing or not preventing (forget which) of detaching the events once they fire. I imagine you need to check if that's on or not and see if it works in the other mode as you would expect. So this may be by design?

[XAML-Knight]

@XAML-Knight I think there's a property about preventing or not preventing (forget which) of detaching the events once they fire. I imagine you need to check if that's on or not and see if it works in the other mode as you would expect. So this may be by design?

Yes, the property in question (IsAlwaysOn) is off, by default. Not sure why there would be a 'Clear' button, then, when the control only logs, from the end user's perspective, 2 log messages. I'd suggest exposing IsAlwaysOn as a toggle button setting/property, that a user can turn off or on.