Bug 1162562 Comment 15 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I did a bit of investigation into this over Christmas.

In the current Windows SDK, there is a preview release of a new API that allows Win32 applications to host UWP UI. I was successfully able to create a window with an Acrylic background that follows the OS theme.

However:

This API has one significant limitation that makes us using the new API non-trivial: Each top-level window must run on its own distinct thread. This is different from our current model, where the Win32 UI thread and the Gecko main thread are one and the same, regardless of the number of top-level windows.

As it stands, we cannot use the UWP XAML Island API without separating the Gecko main thread from our UI threads, and without supporting separate UI threads per top-level window.
I did a bit of investigation into this over Christmas.

In the current Windows SDK, there is a preview release of a new API that allows Win32 applications to host UWP UI. I was successfully able to create a window with an Acrylic background that follows the OS theme.

However:

This API has one significant limitation that makes us using the new API non-trivial: Each top-level window must run on its own distinct thread. This is different from our current model, where the Win32 UI thread and the Gecko main thread are one and the same, regardless of the number of top-level windows.

As it stands, we cannot use the UWP XAML Island API without separating the Gecko main thread from our UI threads, and without supporting separate UI threads per top-level window.

(Of course, I'm sure that some of these problems were already solved back in the Metro Firefox days, but the bottom line is that this would be hard to do incrementally.)

Back to Bug 1162562 Comment 15