Teaching Tip control shows scrollbar on hover even if content does fit

[jemonsivais]

Describe the bug
On the TeachingTip control, if the user hovers over on the right side of the tip, the scroll bar shows even if the content does fit in the control.

Steps to reproduce the bug

Steps to reproduce the behavior:

1. Create a Teaching Tip and show it
2. hover over the right side of the tip

This can be seen on the Xaml Controls Gallery app
Expected behavior

No scroll bar shows if the content fits the control

Screenshots

Version Info

NuGet package version:

Windows 10 version	Saw the problem?
Insider Build (xxxxx)
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
Xbox
Surface Hub
IoT

Additional context

[ranjeshj]

The default for ScrollViewer.VerticalSrollbarVisibility is Visible, we can switch it to auto to get the desired behavior here.

[Felix-Dev]

I would create a PR for that in a bit in case no one is already working on it.

[shaheedmalik]

Shouldn't Auto be the default?

[ranjeshj]

I was expecting it to be auto as well but it does not seem to be. Visible is the default - https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.scrollviewer.verticalscrollbarvisibility?view=winrt-19041
Changing this is a non starter since that would be a breaking change. @RBrid @MikeHillberg Any ideas why Auto was not picked as the default ?

[RBrid]

Don't know why either. It must be inherited from the WPF ScrollViewer: https://docs.microsoft.com/en-us/dotnet/api/system.windows.controls.scrollviewer.verticalscrollbarvisibility?view=netcore-3.1

[Felix-Dev]

Auto seems to make sense here as the default value...could we use the new WinUI ScrollingView to introduce this change (and leave the existing OS XAML ScrollViewer control as is)?

Quoted from #108:

The new ScrollViewer will live in the Microsoft.UI.Xaml.Controls namespace. It's API will be mostly identical to the Windows version. We will make targeted adjustments to the control's API where there is clear benefit (simplify a common scenario, introduce new capabilities, etc).

[RBrid]

Yes indeed, the new ScrollView control uses Auto/Auto for its defaults:

static const winrt::Microsoft::UI::Xaml::Controls::ScrollingScrollBarVisibility s_defaultHorizontalScrollBarVisibility{ winrt::Microsoft::UI::Xaml::Controls::ScrollingScrollBarVisibility::Auto };
static const winrt::Microsoft::UI::Xaml::Controls::ScrollingScrollBarVisibility s_defaultVerticalScrollBarVisibility{ winrt::Microsoft::UI::Xaml::Controls::ScrollingScrollBarVisibility::Auto };

(ScrollView is the new name: #2730).

[jemonsivais]

This could be a ScrollViewer issue instead of TeachingTip, as I have seen this same behavior in controls with ScrollViewer.

[Felix-Dev]

@jemonsivais It's insofar a ScrollViewer issue as what you are seeing here is the default behavior of the ScrollViewer's VerticalScrollBarVisibility mode, which is set to Visible. Setting a new default value for this API in the ScrollViewer would be a breaking change so this won't be done (and there's also a completely new ScrollView control for WinUI 3 in the works which will be based on the ScrollViewer control but improved). We can easily fix this for the TeachingTip control by setting the VerticalScrollBarVisibility of its internal ScrollViewer to Auto (this would be the "fix" in those other cases you are seeing too).

[ranjeshj]

Lets set the property to auto in TeachingTip template to fix this in Teaching Tip. Thanks!