Describe the bug
When you want to use TabView
control in combination with ExtendViewIntoTitleBar
, the tabs are visible underneath the window controls
Steps to reproduce the bug
Follow the guidelines in the docs or see the "Complete TabView windowing sample" in XAML Controls Gallery app.
Expected behavior
TabView should not show up underneath the window controls
Screenshots
Version Info
NuGet package version:
Microsoft.UI.Xaml 2.4.3
| Windows 10 version | Saw the problem? |
| :--------------------------------- | :-------------------- |
| Insider Build (xxxxx) | |
| May 2020 Update (19041) | Yes |
| 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 | Yes |
| Xbox | |
| Surface Hub | |
| IoT | |
Additional context
@stmoy Is this a scenario we actively support/encourage? I know that in the case of the XAML Controls Gallery, that sample has multiple problems which are on our side (i.e. XAML Controls Gallery, not WinUI side).
I think this is useful to support. It's convention now to extend into the title bar even with tabbed interfaces like this example. It should be possible to at least set a custom margin to push the tab headers out from under the window buttons.
You can put content inside the TabStripFooter, e.g. an empty Grid occupying the necessary space to achieve the necessary padding. The question is if there should be a separate API here, similar to the NavigationView.IsTitlelBarAutoPaddingEnabled.
Ah, yes, I forgot about how the NavigationView automatically handles this. It would be great for the TabView to do the same. Both of these controls have evolved into a fundamental layout of applications and should support this scenario the same way.
Is this a scenario we actively support/encourage?
Yes, this is a "mainline" scenario. It's pretty gnarly to get right though...
Resizing the window fixes this issue. I'm not sure if this is a XCG bug or a Title bar bug - it seems like the latter to me especially since there is code to handle this case.
I don't think this is an issue with title bar, the values get passed to the TabView correctly, yet we can end up in that bad state. This is an issue with TabView not responding to the size changes of the TabFooter content. The root cause of this is this line:
https://github.com/microsoft/microsoft-ui-xaml/blob/8c8f29cbf8b6e30e3f26ba208d6d4f44fe26a7ca/dev/TabView/TabView.xaml#L37
Quite frankly, I am not quite sure what the best approach to fixing this would be, @teaP @stmoy @StephenLPeters What do you think?
@stmoy Regarding the mainline scenario, do you think the current way to support this is sufficient (by allowing to add the necessary spacing through the TabFooter) or should we have a separate API that would add the necessary padding automatically? NavigationView also has something similar where it changes the header position to not occlude content.
Regarding the mainline scenario, do you think the current way to support this is sufficient (by allowing to add the necessary spacing through the TabFooter) or should we have a separate API that would add the necessary padding automatically? NavigationView also has something similar where it changes the header position to not occlude content.
The TabFooter spacing isn't optimal, no. I think TabView often takes up the entire window, so this scenario should probably be better supported. Using NavigationView as a precedent for a new API makes sense to me. In the short term, though, it might be faster to fix the bug you highlighted above rather than introducing a new API...
does nav view really have an API to handle this? I would imagine it being more automatic than that
There is the IsTitleBarAutoPaddingEnabled API, which updates the padding on some parts. Having this automatic is very difficult, since that would require some way to reliably detect whether or not the control is the root and is affected by the custom titlebar behavior or not.