MediaPlayerElement created from C++/WinRT crashes when AreTransportControlsEnabled is set to true

[kasperisager]

Describe the bug

Consider the following C++ application:

struct App : public ApplicationT<App> {
  void
  OnLaunched (LaunchActivatedEventArgs const &) {
    MediaPlayerElement player;
    player.AreTransportControlsEnabled(true);

    Window window;
    window.Content(player);
    window.Activate();
  }
};

int
main () {
  init_apartment();

  Application::Start([] (auto &&) { make<App>(); });
}

For some reason, the above application immediately crashes with the following error:

HRESULT_FROM_WIN32(ERROR_INSUFFICIENT_BUFFER) : The data area passed to a system call is too small.

If I remove player.AreTransportControlsEnabled(true) it doesn't crash, but I also don't get any transport controls.

Steps to reproduce the bug

1. Compile and run the code above.

Expected behavior

No response

Screenshots

No response

NuGet package version

WinUI 3 - Windows App SDK 1.4.4: 1.4.231219000

Windows version

Windows 11 (22H2): Build 22621

Additional context

If relevant, this is the manifest used:

<?xml version="1.0" encoding="utf-8"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <assemblyIdentity name="App" version="1.0.0.0" />

  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <dpiAwareness xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">PerMonitorV2</dpiAwareness>
    </windowsSettings>
  </application>

  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <maxversiontested Id="10.0.18362.1"/>
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />
    </application>
  </compatibility>
</assembly>

[DarranRowe]

Does it work if you set AreTransportControlsEnabled to true after you set the MediaPlayerElement as the content of the window?
What about if you use a container control as a container for the MediaPlayerElement? So have the window's content be a Grid or a StackPanel, and then this Grid or StackPanel contains the MediaPlayerElement.

[kasperisager]

@DarranRowe Thanks for the suggestions! All of these also cause a crash unfortunately:

MediaPlayerElement player;

Window window;
window.Content(player);

player.AreTransportControlsEnabled(true);

window.Activate();

MediaPlayerElement player;
player.AreTransportControlsEnabled(true);

Grid grid;
grid.Children().Append(player);

Window window;
window.Content(grid);
window.Activate();

MediaPlayerElement player;
player.AreTransportControlsEnabled(true);

StackPanel panel;
panel.Children().Append(player);

Window window;
window.Content(panel);
window.Activate();

[DarranRowe]

Just to be sure, is your App definition a properly defined App with the metadata being generated by the Xaml compiler?

--Edit--
Yeah.

A properly set up project works. I suspect that you are not implementing IXamlMetadataProvider in App. You would either need to manually implement it as an extra interface, or enable the Xaml compiler in your project.
The Xaml Islands sample should provide enough information to do this. But this doesn't mean that you have to go all in with the Xaml Islands. You should be able to use Application.Start like you are currently doing.
If you are using the Xaml compiler, the two real things you should do is set the ApplicationType element to Windows Store in the .vcxproj and set the App.xaml file to ApplicationDefinition.

[kasperisager]

@DarranRowe Implementing IXamlMetadataProvider and adding the default XAML controls resources did the trick, thanks so much! Is this documented somewhere?

For reference, this is the adjusted App implementation:

struct App : public ApplicationT<App, IXamlMetadataProvider> {
  void
  OnLaunched (LaunchActivatedEventArgs const &) {
    Resources().MergedDictionaries().Append(XamlControlsResources());

    MediaPlayerElement player;
    player.AreTransportControlsEnabled(true);

    Window window;
    window.Content(player);
    window.Activate();
  }

  XamlControlsXamlMetaDataProvider provider;

  IXamlType
  GetXamlType (hstring const &name) {
    return provider.GetXamlType(name);
  }

  IXamlType
  GetXamlType (TypeName const &type) {
    return provider.GetXamlType(type);
  }

  com_array<XmlnsDefinition>
  GetXmlnsDefinitions () {
    return provider.GetXmlnsDefinitions();
  }
};

As an addendum, I'm working on a cross-platform GUI library built and consumed using CMake, hence why I want to stick to plain C++. It's not that I don't think XAML is a worthwhile technology, I simply don't want to push additional build tooling requirements to downstream consumers.

Thanks again!

[DarranRowe]

Yes. The unfortunate thing is that it is documented in the IXamlType documentation. There is a brief explanation in IXamlMetadataProvider too. The issue is that you have to know about this to find the documentation. It would be nice if this was mentioned in the Application documentation.

The other big issue is that the exact requirements are not fully documented. The application's side of the generated code is fully visible though.

So it is possible to figure it out from this code.