The gnome extension (sometimes) causes fonts to fail to load, causing an array of bizarre behavior in some applications including missing text and some programs failing to load entirely. This is due to the behavior in `desktop-launch` and/or `hooks-configure-fonts`. My best guess that I haven't been able to confirm is that this specifically breaks applications that attempt to use vendored fonts that the application itself provides. I discovered this while trying to get wine to run while snapping Lutris, and discovering after making a minimal example[1] that `wineboot --init` fails to copy `.dll` files into the wineprefix if the `gnome` extension is present. Comparing Wine debug logs between the two, it seems that the wineserver begins to explode when loading fonts (somewhere around the CJK fonts) causing a very subtle and silent failure not present when the `gnome` extension is missing. Indeed, even simply copying the `desktop-launch` script and putting it in the command chain in without the gnome extension itself being present will reproduce this. Unsetting, `FONTCONFIG_FILE` in the snap shell before running `wineboot --init` will fix it. This was also corroborated with the Steam snap, which does not use the gnome extension, but does use a hand-modified copy of the `desktop-launch` script (as well as what appears to be parts of the `hooks-configure-fonts` script). Big Picture Mode currently does not display any fonts due to not being able to load from its own `ui-fonts` file, but again, doing `unset FONTCONFIG_FILE` in the snap shell before running it fixes this behavior. The section seems to be doing something valuable in an attempt to make various font sources available within the snap, as well as managing the fonts cache, but in practice something seems to be broken right now that's causing a very subtle failure cascade due to not being able to find certain fonts/configurations in some applications. I have noticed that the generated `fonts.conf`files tend to have weird broken pieces like `/usr/local/share//fonts` which is a valid POSIX path, and even one that actually exists, but the double `//` in many of them makes me wonder if something strange is going on somewhere when doing path discovery/construction. It could be a red herring, but it's strange enough that I wonder if maybe the source of both problems is the same. [1]: https://gist.github.com/ZoopOTheGoop/781bad67844f448403e7e7f41c1b5652