search

dotnet / maui

.NET MAUI is the .NET Multi-platform App UI, a framework for building native device applications spanning mobile, tablet, and desktop.
https://dot.net/maui
MIT License
22.21k stars 1.75k forks source link

ContentView doesn't get correct layout when hosted in legacy renderer #3657

Open filipnavara opened 2 years ago

filipnavara commented 2 years ago

Description

Some controls like the current flyout implementation (and controls in our application) call Platform.GetRenderer on the child control(s). If the child control is ContentView (or a derived type like RefreshView) it gets backed by some default renderer instead of ContentViewHandler. That causes the whole layout logic for ContentView.Content to be missing and not called on iOS (and possibly other platforms). On reinspection the control is still backed by ContentViewHandler but it never gets the layout calls like when hosted directly.

I placed breakpoints in our control. If the ContentView-derived control was placed directly on a Page it was correctly backed by ContentViewHandler and IContentView.CrossPlatformArrange got called from ContentView.LayoutSubviews. However, when placed on FlyoutPage the method IContentView.CrossPlatformArrange never gets called.

Some issues like https://github.com/dotnet/maui/issues/2485 exhibit the same behavior and may have identical root cause.

Steps to Reproduce

Test app: Archive.zip

Run it. If it worked correctly you'd get InvalidOperationException("IF YOU GOT HERE THE BUG IS FIXED"); from the layout call. However, it does not and hence it won't crash.

Version with bug

Preview 10 (current)

Last version that worked well

Unknown/Other

Affected platforms

iOS, I was not able test on other platforms

Affected platform versions

All

Did you find any workaround?

No response

Relevant log output

No response

filipnavara commented 2 years ago

Seems to be root cause of #2422 as well.

shimingsg commented 2 years ago

Verified Repro with iPhone 13 pro max IOS 15.2 and the above project.

ghost commented 2 years ago

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

jfversluis commented 8 months ago

@filipnavara I realize it has been a while. The issues you linked all seem to be resolved. Is this still something you're experiencing?

ghost commented 8 months ago

Hi @filipnavara. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

filipnavara commented 8 months ago

In the last attempt to port to MAUI we abandoned all compatibility renderers so it's no longer an issue for us. I can retest with the original repro linked in the description.

filipnavara commented 8 months ago

Still reproduces when the sample is retargeted to net8.0-ios.

jaosnz-rep commented 8 months ago

@filipnavara Use sample to verify on the latest 17.10 and debug to net8.0-ios. I don't get InvalidOperationException and the application is displayed as black. Is this reproducing the error originally described? image

filipnavara commented 8 months ago

I don't get InvalidOperationException and the application is displayed as black. Is this reproducing the error originally described?

Yes.

The InvalidOperationException is there to drop into debugger if the bug was fixed. Since you didn't get the exception it means it still reproduces.

DanielGlick commented 5 months ago

Was there any resolution to this? I think we are experiencing a similar issue. We are using a RefreshView. I think its similar to #2485, but that one is closed with no apparent resolution.