Skip to content

Conversation

@sharath2727
Copy link
Contributor

@sharath2727 sharath2727 commented Oct 9, 2025

Description

Type of Change

  • New feature (non-breaking change which adds functionality)

Why

We would like to support hosting XAML UI in Fabric.

What

  1. XamlHost tag is introduced to accept xaml ui
  2. XamlHost ComponentView is introduced to setup the xamlisland and connect the island to childsitelink
  3. UIA Automation is now able to understand xaml content hosted in contentislandcomponentview

Testing

Manual testing using SampleAppFabric and hardcoded XAML UI in the xamlisland

Changelog

Should this change be included in the release notes: no_

Microsoft Reviewers: Open in CodeFlow

@sharath2727 sharath2727 changed the title User/sharath227/xamlislandprototypework [DO NOT REVIEW] Xaml UI Hosting Oct 9, 2025
@sharath2727 sharath2727 changed the title [DO NOT REVIEW] Xaml UI Hosting Xaml UI Hosting Nov 4, 2025
@sharath2727 sharath2727 marked this pull request as ready for review November 4, 2025 19:49
@sharath2727 sharath2727 requested review from a team as code owners November 4, 2025 19:49
@acoates-ms
Copy link
Contributor

Can we verify that we are not loading the Xaml dlls on boot when not using any Xaml controls.

}

static winrt::Microsoft::ReactNative::XamlApplication Current() {
return s_current;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if you have a XAML app, and then embed a RNW control within the Xaml App? Seems like in that case, we'd want to be using the already existing XamlApp?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's true there can only be one instance of MUX.Application in the process. But unfortunately MUX.Application doesn't let you add more metadata dynamically, so I thought it'd be good to have this type to allow multiple Xaml-based components to coordinate.

I'm not sure offhand the best way to handle the case where the host already has a MUX Application. Can we file an issue to follow up on that later, or is it urgent to solve? Thanks!

};

[webhosthidden]
interface IXamlControl
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we move this into a Microsoft.ReactNative.Xaml namespace? I'd like the try to keep any Xaml specific stuff out of core to ensure we have nice layering.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

// Copyright (c) Microsoft Corporation.
// Licensed under the MIT License.

namespace Microsoft.ReactNative {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MS.RN.Xaml namespace?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

// m_providers.push_back(winrt::make_self<XamlMetaDataProvider>().as<winrt::Microsoft::UI::Xaml::Markup::IXamlMetadataProvider>());
s_current = *this;

// TODO: It's probably not a good idea to only load the controls pri file, there are other ones too.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please file a follow-up issue to investigate this one at a later time. It might be an issue when folks want to load a more complex Xaml user control, we might eventually want a way to let the app declare its own .pri file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I understand. Will create a task for follow up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

// This is similar to ViewComponentView::hitTest, but we don't want to hit test the children of this node,
// because the child ComponentView is kind of a dummy representation of the XamlElement and doesn't do anything.
// So, we just hit test the ContentIsland itself to make the UIA ElementProviderFromPoint call work.
// TODO: Will this cause a problem -- does this function need to do something different for non-UIA scenarios?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious of Andrew's thoughts on the best way to handle ContentIslandComponentView::hitTest

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why do you need this override? What kinds of components are you putting in the ContentIslandComponentView? I'd expect that the components you'd be putting in the XamlHost view would be Xaml components. And those should not inherit from ViewComponent, so they would be ignored by the default hit test, no?

@JesseCol
Copy link
Contributor

JesseCol commented Nov 5, 2025

There's an older Xaml sample in sample-custom-component called CalendarView, it'd be nice to delete that one as this goes in.

There's also one in playground-composition\CustomComponent.cpp we might want to delete.

This is looking fine to me, but I want to make sure we get Andrew's approval. Thanks!

Copy link
Contributor

@JesseCol JesseCol left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be great to get in, thanks! Please make sure you get Andrew's approval.

@sharath2727
Copy link
Contributor Author

Can we verify that we are not loading the Xaml dlls on boot when not using any Xaml controls.

Yeah we are not introducing any Xaml dll's. All these come into picture when RegisterXamlHostNativeComponent is triggered from the 3P Module.

this->ResourceManagerRequested([resourceManager](auto &&, ResourceManagerRequestedEventArgs args) {
args.CustomResourceManager(resourceManager);
});
winrt::Microsoft::UI::Xaml::Hosting::WindowsXamlManager::InitializeForCurrentThread();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will XamlApplication be instantiated if there are no XamlHost tags used in an RNW app (either directly or indirectly via modules)?

WindowsXamlManager::InitializeForCurrentThread is known to be a slow function. We need to be sure we don't penalize the mainline scenario (RNW apps with no XAML usage) for a special case scenario.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It won't be instantiated. It will only be created when XamlHostComponentView is initialized.

Comment on lines -181 to -188
assert(false);
base_type::MountChildComponentView(childComponentView, index);
}

void ContentIslandComponentView::UnmountChildComponentView(
const winrt::Microsoft::ReactNative::ComponentView &childComponentView,
uint32_t index) noexcept {
assert(false);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were these asserts originally put to ensure control doesn't reach here? More like unreachable code but now we've a genuine islands scenario that have them removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes sundar

Comment on lines +62 to +67
for (const auto &provider : m_providers) {
auto definitionsCurrentProvider = provider.GetXmlnsDefinitions();
for (const auto &definition : definitionsCurrentProvider) {
allDefinitions.insert(allDefinitions.begin(), definition);
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Inserting to the front of a vector is better avoided generally as all following elements needs to be reseated (slow). Unless the order of the definitions is important, this will be faster:

for (const auto &provider: m_providers) {
  const auto& definitions = provider.GetXmlnsDefinitions();
  allDefinitions.insert(allDefinitions.cend(), definitions.cbegin(), definitions.cend());
}

auto uiaProvider =
winrt::get_self<winrt::Microsoft::ReactNative::implementation::ComponentView>(view)->EnsureUiaProvider();

// TODO: Avoid exposing CompositionDynamicAutomationProvider in RootComponentView
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please file a follow-up task for this and paste its link here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#15317 - I already created a task and adding pending sub tasks to it. Will add this here.

@microsoft-github-policy-service microsoft-github-policy-service bot added Needs: Author Feedback The issue/PR needs activity from its author (label drives bot activity) and removed Needs: Author Feedback The issue/PR needs activity from its author (label drives bot activity) labels Nov 7, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants