[iOS, Android] DrawerControl.DrawerContent isn't set on mobile but works on win

[Lee31416]

Current behavior

On mobile we can see the overlay but the drawer content is nowhere to be found

Expected behavior

On windows we can see that the drawer content is there

How to reproduce it (as minimally and precisely as possible)

1. Download the sample SampleDrawerEdgeSwipe.zip
2. Deploy the sample on windows
3. Swipe with the mouse or click on the button to open the pane
4. Deploy on either ios or android
5. Swipe or click the button to open the pane and see that the content isn't there

Workaround

None found

Works on UWP/WinUI

Yes

Environment

Uno.UI / Uno.UI.WebAssembly / Uno.UI.Skia, Uno.UI.RemoteControl / Uno.WinUI.RemoteControl

NuGet package version(s)

4.8.15

Affected platforms

Android, iOS

IDE

Visual Studio 2019

IDE version

17.6.2

Relevant plugins

No response

Anything else we need to know?

Before we used a drawer control but we had issues with it so we switched to a split view but the native splitview doesn't have gestures so we took the DrawerSplitViewStylestyle and that's when the bug appeared. So maybe the combination of a drawer control inside a splitview is causing this issue.

[Xiaoy312]

This is the result of {TemplateBinding} not applying properly in uno: #1621 The nested template doesnt inherit the proper templated-parent, for the binding to work:

ContentControl#DrawerTemplate_DrawerContentControl // TemplatedParent=DrawerControl#SplitView_TemplateRoot, Content=ContentControl#Drawer_PaneHolder
    ContentPresenter // TemplatedParent=ContentControl#DrawerTemplate_DrawerContentControl, Content=ContentControl#Drawer_PaneHolder
        ContentControl#Drawer_PaneHolder // TemplatedParent=DrawerControl#SplitView_TemplateRoot, Content= // <--
            ContentPresenter // TemplatedParent=ContentControl#Drawer_PaneHolder, Content=

templates are slightly modified to help identify element (click here to see details)

``` MainPage // TemplatedParent=, Content=SplitView#RootSplitView SplitView#RootSplitView // TemplatedParent=, Content=StackPanel#SplitView_ContentPanel, Pane=TextBlock#SplitView_PaneContentText DrawerControl#SplitView_TemplateRoot // TemplatedParent=SplitView#RootSplitView, Content=ContentControl#Drawer_ContentHolder, DrawerContent=ContentControl#Drawer_PaneHolder StackPanel#RootPanel // TemplatedParent=DrawerControl#SplitView_TemplateRoot [--TO IGNORE--]ContentControl#DrawerContentControl // TemplatedParent=DrawerControl#SplitView_TemplateRoot, Content= ContentPresenter // TemplatedParent=ContentControl#DrawerContentControl, Content= ContentControl#DrawerTemplate_ContentControl // TemplatedParent=DrawerControl#SplitView_TemplateRoot, Content=ContentControl#Drawer_ContentHolder ContentPresenter // TemplatedParent=ContentControl#DrawerTemplate_ContentControl, Content=ContentControl#Drawer_ContentHolder ContentControl#Drawer_ContentHolder // TemplatedParent=DrawerControl#SplitView_TemplateRoot, Content=ContentControl#Drawer_ContentHolder ContentPresenter // TemplatedParent=ContentControl#Drawer_ContentHolder, Content=ContentControl#Drawer_ContentHolder ContentControl#DrawerTemplate_DrawerContentControl // TemplatedParent=DrawerControl#SplitView_TemplateRoot, Content=ContentControl#Drawer_PaneHolder ContentPresenter // TemplatedParent=ContentControl#DrawerTemplate_DrawerContentControl, Content=ContentControl#Drawer_PaneHolder ContentControl#Drawer_PaneHolder // TemplatedParent=DrawerControl#SplitView_TemplateRoot, Content= ContentPresenter // TemplatedParent=ContentControl#Drawer_PaneHolder, Content= ```

^ the Drawer_PaneHolder here is supposed to have SplitView#RootSplitView for its templated-parent, as it is defined directly under the control-template for SplitView.

[Xiaoy312]

The very same problem can also be produced with XamlReader.Load, hints that the problem is how we handles {TemplateBinding} or {Binding RelativeSource={RelativeSource TemplatedParent}}. However, it is impossible to trace-back under which control-template it was define under, as we can't just blindly navigate up by n-levels. We will have to do as the linked issue suggested, to inject the relevant context/templated-parent during the xaml-source-generation or XamlReader-loading.