[x86] CTCatalog - Font Functions - crashes when attempting to change Select nameKey #1865
Comments
|
Seems to be introduced in 88975ca |
|
We recently shifted Islandwood over to not using queued CATransactions for its UIElement property and hierarchy management; instead we perform the property/hierarchy changes synchronously on the backing Xaml elements as they’re issued by the app. This change was required to fix several other bugs, and it should also lead to a much more simplified Islandwood implementation layer. It’s worked pretty well so far, but it’s uncovered an interesting issue with ScrollViewer’s ScrollViewerViewChangedEvent. CTCatalog has a UIPickerView within a UITableView. Selecting an item in the UIPickerView results in reloading the entire parent UITableView’s data, which ends up removing and re-adding all of that UITableView’s contents. We don’t actually delete/recreate the UIPickerView, but it is temporarily removed from the UIElement tree, and then added back as the UITableView rebuilds its content. This may sound odd, but it’s a perfectly valid use of UITableView’s reloadData method. Just as on iOS, our UIPickerView is built upon our UIScrollView (which is backed by a Xaml ScrollViewer). The UIPickerView’s ‘selection changed’ event is fired as a result of the UIScrollView’s ‘scrollViewDidScroll’ event, which is keyed off of the Xaml ScrollViewer’s ScrollViewerViewChangedEvent. This is where the issue lies. The ScrollViewerViewChangedEvent is fired during Arrange, and removing the ScrollViewer from the UI during this event handler leads to an AV in CFrameworkElement::ArrangeCore because the ScrollViewer’s m_pLayoutStorage was deleted. Here's the full stack where we remove the ScrollViewer from the UIElement tree. Windows.UI.Xaml.dll!DirectUI::PresentationFrameworkCollectionTemplateBase<Windows::UI::Xaml::UIElement >::RemoveAt(unsigned int index) Line 872 C++ …which results in an AV at Windows.UI.Xaml.dll!CFrameworkElement::ArrangeCore(XRECTF_WH finalRect) Line 1855: It seems a bit odd that ScrollViewer raises ScrollViewerViewChangedEvent within Arrange; MSDN doesn’t call this out as a limitation. Ideally we’d be able to do whatever we want within the ScrollViewerViewChangedEvent, including removing the ScrollViewer from the UIElement tree. |
|
We have a few options;
We'll need to discuss our options here; I think 3 sounds the most promising if we can prove that it won't cause other issues. |
…Xaml ScrollViewer's ScrollViewerViewChanged event leads to an AV in Xaml if the delegate removes the UIScrollView from the Xaml UIElement tree. To work around the issue, push the delegate call to a subsequent run of the UI thread. Fixes microsoft#1865.
ArnOmsft
changed the title
…Xaml ScrollViewer's ScrollViewerViewChanged event leads to an AV in Xaml if the delegate removes the UIScrollView from the Xaml UIElement tree. To work around the issue, push the delegate call to a subsequent run of the UI thread. Fixes microsoft#1865.
|
@tadam-msft, what do you want to do with this one? |
|
Option 3 |
This is on the 1701 payload that's in master - 20170127.1
The text was updated successfully, but these errors were encountered: