Fixing ScrollBar regression for Issue #4255

[RBrid]

Fixes #4255

We recently added a 1px margin around the ScrollBar, in its default control template. That potentially caused a layout cycle on DPI levels other than 100%. The chosen solution is to remove that ScrollBar 1px margin and add instead a 1px padding where it's used the most: the ScrollViewer control.

So the ScrollViewer's control template is declared in WinUI 2.6 now and includes 2 new Grid elements around the ScrollBar controls, with a 1px Padding around them.

Only ScrollViewer_themeresources.xaml has the additional Grid elements (just like only ScrollBar_themeresources.xaml had the 1px margin).

The same trick is used in the new WinUI ScrollView control. Its default control template now includes 2 additional Grid elements surrounding its ScrollBar controls.

While in there, I also fixed a couple of things:

• Updated ScrollViewScrollBarsSeparatorBackground as it is meant to be transparent now like the ScrollViewer's scrollbars separator.
• Fixed ScrollViewerScrollBarSeparatorBackground for HighContrast as it is supposed to use SystemControlTransparentBrush and not ControlFillColorTransparentBrush.

[RBrid]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[RBrid]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[RBrid]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[robloo]

@RBrid

This looks like a work-around not a fix. As someone who has spent a lot of time also trying to work-around the 'Layout Cycle Detected' bugs that crop up in apps I'm more interested in what the actual root cause of this is. Is there any plan to address what I assume are rounding errors in the layout math with WinUI 3? It shouldn't be possible to trigger a layout cycle exception by just adding a margin. Something deep is broken and it's going to keep popping up.

[RBrid]

@robloo, I agree with you completely. This is a workaround rather than a fix - my title/comments should have been clearer about this, like my branch name user/regisb/ScrollBarWorkaround5.

We opted for a WinUI 2.6 workaround rather than shipping a QFE in every Windows OS version supported by WinUI 2.6. At this point we do not know the exact root cause and its location. It is likely in our layout engine, or maybe the ScrollBar code itself. It is a rounding error for sure, and again I agree that adding any Margin should not cause a layout cycle. We do have an open internal bug to track this issue for WinUI3+. Thanks.

[robloo]

@RBrid Thanks for the details. It makes sense to skip the full fix for WinUI 2.x and instead focus resources on WinUI 3. I just wanted to be sure it wasn't going untracked. Glad to hear there is an internal bug.