Fredrik Roubert

Newly released 6.19.0 (which uses Electron 24.3.0) doesn't work with Wayland for me (Debian _bookworm_ amd64), even though running `signal-desktop` with `--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations` worked fine until 6.18.1 (which used Electron...

I have a fairly standard Debian _bookworm_ amd64 installation, using the default GNOME desktop enviroment on Wayland, with the only obvious non-standard thing being this additional `--ozone-platform-hint=auto --enable-features=WaylandWindowDecorations` passed to...

Yes, that is exactly what I did, just as described in that support page I linked to.

I've now updated to newly released 6.20.0 (which also uses Electron 24.3.0) and the problem persists (just as expected).

> Is Wayland supported/tested or should we expect issues? I don't know whether Wayland is officially supported by Signal, but I also don't think that matters very much for this...

> Another way to attack this, that would be much faster, is not try resource fallback for every one of the variants in a locale. This seems like a very...

> This would be really good to figure out, but shouldn't block other progress. OK, if putting limits on the length and number of variants is the best path forward,...

> > First of all, I'd like to have a unit test for this that fails if language tags with too long or too many variants are accepted, so that...

While I think the updated test is much better as it now will fail if the rejection of overlong variants fails, I still don't understand why you don't want to...

> But that test does not verify the hang in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65761 no longer hang. I still don't get it. The reason that `DateTimePatternGenerator::createInstance()` runs for a very long time (it...