[WASM] Page Loading Fails - Potentially because 2 nested XAML controls in a direct parent/child get instantiated/InitializeComponented/loaded in different order between WASM / WinUI #10276
Replies: 8 comments 6 replies
-
|
UPDATE : One thing I noticed (not sure if it is important or just an oddity of the way logging happens) --- but the order in which the various objects is getting instantiated appears to be different between WinUI & WASM: On WinUI - this is what happens But on WASM the order is different (observe the three entries between the blank lines). Plus on WInUI the log continues to to capture all the expected events, but on WASM we just see all these "The thread 0x????? has exited" statements. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the details. If you can provide a repro for your issue, it'll be useful. The messages Note that the order of some events for the |
Beta Was this translation helpful? Give feedback.
-
|
Ok, I get that "The thread has exited" is part of the execution process - but on WinUI it goes on and logs all the rest of the content related to the control loading - whereas on WASM it just stops. Also - overnight I removed all the references to DependencyProperty.Registration & commented out all the XAML references to the property. It still just suspends - but it isn't related to DependencyProperty as I initially thought. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I am defiantly using a XAML to define " 2 controls in a direct parent/child relationship (on the logical tree) called outer and inner" exactly as detailed in #3519. I will remove the nesting, and load the controls programmatically in code to see what happens. I'll get back to you. |
Beta Was this translation helpful? Give feedback.
-
|
Upon closer inspection, I am noticing when I UNLOAD the WinUI project head and then only have the WASM project head - I wee this blue squiggly warning in the XAML that "The type Control Template does not support direct content". I don't see this when the Windows project is loaded. I am assuming that this is similar to the red squiggly you see related to InitializeComponent() and other items in the code that have been named inside XAML with the x:Name="MyControl". This is only a VisualStudio artifact, right? Its not a limitation of WASM vs WinUI ? |
Beta Was this translation helpful? Give feedback.
-
|
This is indeed a Visual Studio issue. There's been progress on this in VS 17.4, which should be released at .NET conf |
Beta Was this translation helpful? Give feedback.
-
|
OK - I spend 3 days tying to get this to work - but its an absolutely no better. I added a bunch of Logging - and I am finding that it is not just an issue with the order in which the constructors are called, but there are WinUI/WASM differences in the sequence in which the DataContext is set and the Load events are called. It seems like on WinUI all the constructors are called - then the DataContext ( InitializeComponented() ) is set on the leaf nodes before the branches and the trunk, and then finally the load event (starting with the leaf nodes first). On WinUI - this is what happens But on WASM - not only is the order of the constructors different - the InitializeComponented() and Load() events appear to happen in a different order between WinUI & WASM. On WASM the page level Loaded event happens first, then the leaf nodes try to initialize. However, because the DataContext does not appear to have been set before the Loaded event is fired on WASM, the control's view model data does not seem to be available to continue the rendering process then it simply ABENDS after only a few steps. This issue feels identical to the issue I opened two years ago Uno.Shared Page/UserControl Events Fired In Different Order ( UPW vs WASM ) #4072 ( which was flagged as a duplicate of Loading, Loaded & Unloaded events are called too early #2895 ). However, it isn't clear that just changing just the _Loading, Loaded & Unloaded order fixes the entire DataContext ( InitializeComponented() ) sequence issue - maybe it will. I also see that there is also [EPIC] Controls initialization sequence #3519 - which is more comprehensive. At this point, given that we originally opened #4072 more than two years ago - and and are still unable to render our custom controls - I feel like I have to report to my management that Uno on WASM is not fit for purpose. |
Beta Was this translation helpful? Give feedback.
-
|
As I mentioned previously, if you can get a specific repro to your issue (an individual project based on the Uno template, demonstrating explicitly the issue), we may be able to find a different way to get you going. It looks like you have that somehow, so can you make it available? The important part for the repro is the scenario you're trying to get to, not necessarily the issue you're hitting. |
Beta Was this translation helpful? Give feedback.
-
|
Per your request, I have mocked up a very simple repository that demonstrates the divergence between WinUI and WASM. This illustrates the issues in as little code as possible. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, this will help! |
Beta Was this translation helpful? Give feedback.
-
|
So I augmented the test harness app in the UnoBug2895Test repository (described above) such that it renders three shapes on the left canvas. The shapes are passed as a list, from MainPage => SideBySideGridPage (via OnNavigatedTo() parameter) => ViewModel_LeftCanvas. The LeftCanvas control then renders each of the shapes in response to an PropertyChanged event emitted from the view model. Each control in the list is positioned on top previous control, and is sized to be slightly smaller than its predecessor. The canvas reacts to OnSizeChanged() events, and resizes each of the controls appropriately, given the size of the control just beneath it. This is a reasonable chain of events that both WinUI & WASM should be able to support without any platform specific customizations. However, where it works fine on WinUI, it fails on WASM.
On WASM, only the first control is rendered properly (even though all three are in the canvas' Children collection). Because each control relies on size of the previous control to determine its own size, WASM is unable to compute the height/width of the the 2nd/3rd controls - and simply sets their size to zero. NOTE how on WinUI the Height/Weight ( and ActualHeight/ActualWeight ) values are properly initialized by the second resize event. However on WASM, the Height/Weight ( and ActualHeight/ActualWeight ) values never change from ZERO |
Beta Was this translation helpful? Give feedback.
-
|
(When answering to a discussion, prefer answering to the thread rahter than creating a new thread. It easier to follow) Thanks for the updates. There are two issues here (It's generally best to have a repro for each individual one to avoid altering the behaviors). The first issue is caused the fact that Generic.xaml is not processed when defined in the main app (it's rarely used, which is why we never saw this, let's track in #10327), causing OnApplyTemplate to not be called. To work around this, move the <Application.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<XamlControlsResources xmlns="using:Microsoft.UI.Xaml.Controls" />
<ResourceDictionary Source="Styles/Controls.xaml" />
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Application.Resources>The second issue is related to the use of It's likely that you'll want to create a |
Beta Was this translation helpful? Give feedback.
-
|
Ok, so made the following changes in (as directed) to the bugtest repository
I was able to get that to draw the tree shapes identically on WinUI & WASM. However, there was still a significant inconsistency between WinUI/WASM WASM doesn't fire OnDataContextChanged when the DataContext is derived from a parent control in XAML hierarchy. I was able to HACK around it but my hack wouldn't work if the parent control's DataContext instance was somehow replaced during runtime. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the update. If you can provide an individual repro sample for this, it will help. |
Beta Was this translation helpful? Give feedback.
-
My app uses DependencyProperty.Registration to create XAML bindable properties for our custom charting controls. On WinUI it works fine - but not on WASM.
I observe in the Uno documentation & code that Uno does not support PropertyMetadata.Create(...) on WASM because there is a NotImplemented attribute on the Create() method.
However, there is no NotImplemented attribute on the constructor - so I would infer that it should work.
Yet, when I create an instance of one of these controls, the app simply stops executing ( yet doesn't crash). It just wont create an instance of the class ( no log entries / console.writelines placed inside the constructor are observed ) when using WASM. Although, again, in WinUI it works fine.
One thing that ?MIGHT? be related is that when I navigate away from the page that contains the control - and then try to return ( i.e. display the control a second time ). I see this error in the output:
I haven't tried to troubleshoot this yet, so it could be entirely unrelated.
Beta Was this translation helpful? Give feedback.
All reactions