It's a real shame that platform native widgets had to be sacrificed for this to work. The easy way out was to switch to arbitrary app-drawn widgets across all platforms (which Firefox did for all basic DOM HTML elements); the "we'll do one better" alternative is to use app-drawn imitations of the system-native widgets (a la Qt) which Firefox is now doing for the scrollbar. But no one ever gets these widgets right (unnatural scrolling, non-identical behavior when clicking in the gapped region, different scrollable-to-nonscrollable widget ratios, colors not respecting certain subtle theming choices, etc, etc.
I wonder if there was an alternative specifically for the scrollbar here - some way of obtaining an outer "shell" (via win32k, but then basically "orphaning" it so that you can't do anything besides kill it when you're finished) that just provides the window with an empty scrollable element that is then populated by the restricted process.
That ship has really sailed though; I think the days of native widgets are quickly coming to an end.
There already is a safe API with Wayland + some sandboxing layer. Problem is for the longest time the Nvidia drivers didn't work with Wayland. They now do so the reasons to use X11 become vanishingly small.
Firefox already used uxtheme for that. A lot of programs and toolkits do, since the heavyweight HWND-based comctl32 controls aren't suitable for things like browsers because they're slow, hard to render without flicker, there's a limit on how many you can have, they don't play well with effects like opacity and transform3d() and so on. Even Internet Explorer did[1].
I guess uxtheme is unsuitable for win32k lockdown for some reason, probably because it's GDI-based.
(I used to work on the blog author’s team, and in fact dealt with some of the COM issues mentioned in the post)
You’re right, uxtheme can’t be called directly from content because of win32k dependencies. One option could be for content to request the parent to draw those controls, but as you can imagine there are drawbacks to doing that. As usual, there are a lot of trade offs involved.
I wonder if there was an alternative specifically for the scrollbar here - some way of obtaining an outer "shell" (via win32k, but then basically "orphaning" it so that you can't do anything besides kill it when you're finished) that just provides the window with an empty scrollable element that is then populated by the restricted process.
That ship has really sailed though; I think the days of native widgets are quickly coming to an end.