Call RootViewChanged when setting ContentView to null#20052
Call RootViewChanged when setting ContentView to null#20052PureWeen merged 5 commits intodotnet:mainfrom
Conversation
|
/rebase |
304756f to
ec99792
Compare
|
|
||
| _viewFragment = null; | ||
|
|
||
| RootViewChanged?.Invoke(this, EventArgs.Empty); |
There was a problem hiding this comment.
Did you validate this with page swapping variations?
If the user swaps the main page for a different shell page
If they swap it for non shell then swap back to a shell page?
The main thing I'm curious about is if the "remove" path is followed if we need to wait for that to finish before calling RootViewChanged
There was a problem hiding this comment.
Should be fixed with 2f4cd0c, as I wrote below it's unrelated to what I was addressing with this PR (you would have hit this in current MAUI stable switching any Window main page.)
The issue is the way the layers work with Android and where the graphics layout is put. When we initialize the VisualDiagnosticsOverlay for Android, it goes on the top most layout of the view, which just so happens to be whatever the current Page content for a given Window is. That is unlike iOS/Mac/Windows where it's put above every MAUI view so it works regardless of switching out the page. With Android we need to recreate the overlay if you swap out the MainPage of a given window, since swapping it takes out the graphics layer.
# Conflicts: # src/Core/src/Platform/Android/Navigation/NavigationRootManager.cs
|
I am not sure what this image is meant to represent. Having a series of steps you took would be nice rather than a png. e. Okay, I think I understand. If you take an existing Shell page, and swap it for something else, the WindowOverlay view does "break" and doesn't render new content... I tried it in the current MAUI 8.x stable and it does the same thing. It's also unrelated to Shell, you can swap two normal pages in a window and it will do the same thing. That's because WindowOverlay doesn't get deinitialized when the page is removed, meaning that when the new page is set, the WindowOverlay. IsPlatformViewInitialized is already set to true, so the new content isn't tracked. It's unrelated to LVT and the Hot Reload stack, and it's a separate issue from what I'm fixing here. e2. should be fixed with 2f4cd0c |
|
@PureWeen Can you please look at this again? The root page issue should be fixed. |
|
/rebase |
|
/rebase |

Looking at the original issue as I tried to fix it, I think other code was refactored that caused the the RootManager.RootView to remain null in the new code I introduced. Stepping through it, I saw that
OnWindowContentPlatformViewCreatedinvokedRootViewChanged, which the Visual Diagnostics Overlay uses to then create its overlay for. This is never called for Shell, which is what my original code tried to force, but since the RootManager.RootView was null, it still wasn't being called.This fixes it by revering the changes for OnWindowContentPlatformViewCreated and instead calling
RootViewChangedinside of SetContentView. For Shell, the ContentView is set to null, as its fragments are handled elsewhere. By calling RootViewChanged here, the VisualDiagnosticsOverlay can then access RootManager with RootView initialized.Description of Change
Issues Fixed
Fixes #17677