I’m experiencing puzzling behavior with emojis on a few specific Firefox profiles, both on Windows 10 and on Android 10.
Inside these problematic profiles, whenever a Discourse conversation page loads, all emojis within it that page remain “untranslated”, by which I mean: their description string (the string sitting in between two colons, like
:smiling_donkey:) is displayed raw, instead of the actual emojis being displayed. However, if I then either:
- toggle NoScript from trusted to untrusted, then back to trusted
- toggle AdGuard AdBlocker from enabled to disabled on that page
or—and this is where things get surprising:
- initially load the page with a disabled AdGuard AdBlocker, and the toggle it from disabled to enabled on that same page
then the page reloads and all emojis are displayed as expected.
A simple page refresh (F5) however does not cause emojis to be displayed as expected. Something unrelated to the core functionality of NoScript, yet somehow tied to this add-on seems to be messing with emojis.
This behavior persists even if the AdGuard AdBlocker is removed, or even when it is never installed. But the manner in which it triggers a page reload seems different enough from a normal F5-triggered refresh to get emojis to be shown. Similarly to the way NoScript itself causes pages to reload after its domain permissions are modified.
Using a fresh new profile hasn’t solved this issue, so I’d appreciate any insight as to what might be causing this.