We have code in various places that imitates native scrollbars but respects a CSS-controllable "scrollbar color". We should make sure that this keeps working with the non-native theme.
Maybe we can even use the same code as today, on each platform. For example, when the non-native theme is enabled on macOS we'd still want rounded scrollbars. The current scrollbar-color-aware scrollbar drawing code on macOS knows how to draw rounded scrollbars, without the help from the OS, as far as I know.
Then we can also use the macOS non-native scrollbar drawing code for Android scrollbars.

They work already, see bug 1615028.

But we should probably do the widget-side painting, probably.

The arrows at the ends aren’t being drawn on Windows, which I presume is because of this. I consider this quite important, as it makes scrollbars feel very wrong. I think this is what feels most wrong about it to me: if glancing to see if something is scrollable, I look to the corners and see the arrows, but this means that I look at something and don’t see it as obviously scrollable (since the scrollbar track colour is regularly being set to transparent or to match the colour beside it, as here on Bugzilla).

I also note with curiosity that if I set a scrollbar-color (which changes it to use the wrong rendering), and then remove it, it continues to use the wrong rendering until the scrollable element leaves and reenters the document.

(Incidentally, Chrome suffers from the same missing-arrows problem if you customise the scrollbar with ::-webkit-scrollbar, which is a part of the reason why I declined to add it to Fastmail’s dark theme, because I found that worse than the light scrollbar. If Firefox ships a non-native theme without arrows, I’ll suggest scrapping the scrollbar-color declaration just to get them back—though hopefully I’ll be able to figure out exactly how to trigger the dark/light scrollbar guessing, which it doesn’t get right there at present.)

The arrows at the ends aren’t being drawn on Windows, which I presume is because of this. I consider this quite important, as it makes scrollbars feel very wrong. I think this is what feels most wrong about it to me: if glancing to see if something is scrollable, I look to the corners and see the arrows, but this means that I look at something and don’t see it as obviously scrollable (since the scrollbar track colour is regularly being set to transparent or to match the colour beside it, as here on Bugzilla).

Ah, that's good to know. I'm on Linux and my default gtk theme doesn't have arrows anyway, and thus the scrollbars look fine, heh.

In that case, then the solution in comment 1 should fix it. We just need to make the integration with the scrollbars a bit tighter.

I also note with curiosity that if I set a scrollbar-color (which changes it to use the wrong rendering), and then remove it, it continues to use the wrong rendering until the scrollable element leaves and reenters the document.

That sounds like an invalidation issue... I think that can cause issues right now on gtk themes with scroll arrows. Not sure how common they are but we should get that on file separately anyway.

(Incidentally, Chrome suffers from the same missing-arrows problem if you customise the scrollbar with ::-webkit-scrollbar, which is a part of the reason why I declined to add it to Fastmail’s dark theme, because I found that worse than the light scrollbar. If Firefox ships a non-native theme without arrows, I’ll suggest scrapping the scrollbar-color declaration just to get them back—though hopefully I’ll be able to figure out exactly how to trigger the dark/light scrollbar guessing, which it doesn’t get right there at present.)

Yup yup, that's all understandable, thanks for writing it down. The dark scrollbar guessing right now lives in nsNativeThemeWin, and thus you can't trigger it with the non-native theme. But we should also implement it.

The code is here btw, and the actual heuristic is here.

Tracking non-native theming bugs for Fission Beta milestone (M7).

The Windows side of this bug will be addressed in bug 1615038. Marking this bug as blocking bug 1535761 now instead of bug 1687022 to reflect the fact that other platforms may still require work to properly support this.

Emilio, is there work for linux NNT here? Asking because linux-nnt is a Fission blocker but shipping NNT on other platforms is not.

scrollbar-color seems to work fine with Linux NNT.

Not a Fission bug

It works.