-
Notifications
You must be signed in to change notification settings - Fork 8.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rebuild the profile nav via MenuItemsSource; mitigate a crash #14630
Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, if it works, it works haha. The ReplaceAll()
we were doing was also a workaround so at this point I'll take what I can get :P
@@ -527,7 +536,7 @@ namespace winrt::Microsoft::Terminal::Settings::Editor::implementation | |||
|
|||
void MainPage::_InitializeProfilesList() | |||
{ | |||
const auto menuItems = SettingsNav().MenuItems(); | |||
const auto menuItems = SettingsNav().MenuItemsSource().try_as<Windows::Foundation::Collections::IVector<IInspectable>>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This introduces an ordering dependency, right? It seems like there is code that can run before MenuItemsSource
is set and code that can only run after. Are we clear on what happens here if somehow it's not been set?
@@ -555,6 +564,30 @@ namespace winrt::Microsoft::Terminal::Settings::Editor::implementation | |||
menuItems.Append(addProfileItem); | |||
} | |||
|
|||
void MainPage::_SetupNavViewItems() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For clarity, I might recommend we be very specific about what this does.
_moveXAMLParsedNavItemsIntoItemSource
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In fact, we should make it a debug assert that it never fires twice
…ce, to mitigate a crash
Directly manipulating the `NavigationView::MenuItems` vector is bad. If you do that, you're gonna get crashes, in WinUI code for `Measure`. However, a WinUI PR (below) gave me an idea: Changing `NavigationView::MenuItemsSource` will wholly invalidate the entirety of the nav view items, and that will avoid the crash. This code does that. It's a wee bit janky, but it works. Closes #13673 _might_ affect #12333, need to try and repro. See also: * #9273 * #10390 * microsoft/microsoft-ui-xaml#6302 * microsoft/microsoft-ui-xaml#3138, which was the fix for microsoft/microsoft-ui-xaml#2818 (cherry picked from commit 8c17475) Service-Card-Id: 88428128 Service-Version: 1.17
* make the list of MenuItems observable, so the nav view can actually listen for changes to it * Use the MenuItemsSource to find the index to add at, rather than the MenuItems (which isn't accurate anymore) * Stash a single observable vector as the menuitemsource, and modify that whenever we need to do modifications. * I attempted to create a new vector, then copy into the new one, then replace the MenuItemsSource with the new vector, but that _refused_ to work. So let's just... not. Regressed in #14630 Closes #15140 Manually validated that this and #13673 are still fixed
Directly manipulating the
NavigationView::MenuItems
vector is bad. If you do that, you're gonna get crashes, in WinUI code forMeasure
. However, a WinUI PR (below) gave me an idea: ChangingNavigationView::MenuItemsSource
will wholly invalidate the entirety of the nav view items, and that will avoid the crash.This code does that. It's a wee bit janky, but it works.
Closes #13673
might affect #12333, need to try and repro.
See also: