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
or
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.
When you say NoScript here, what do you mean? Is this a browser feature or browser add-on or how are you enabling NoScript? Emojis work well on Firefox for me though and I use adblockers and enabled Firefox’s tracking protection too.
I think the developer of NoScript would probably issue me a reply along similar lines: “This isn’t a NoScript issue because you’ve enabled scripts yet their site is broken”, or something to that effect.
This really feels like a corner case caused by a weird interaction between Discourse, NoScript, and probably something else. Especially due to the fact that this issue does not systematically occur in my Firefox profiles where NoScript is installed. Perhaps an underlying bug could be tracked down if I was provided with some help in tracking down what’s going on?
We only test against vanilla versions of our supported browsers, and since that works fine (half our team uses Firefox as their daily driver) there is nothing here for us to do. We can’t afford to track down bugs introduced the numerous browser extensions.
As you wish
There’s obviously something weird going on that is specific to what Discourse code is doing to the page, though. I’ve been a NoScript user for more than ten years, and this is the first of a kind. Let’s hope there won’t be any other side effects to this mysterious behavior down the road.
and I use adblockers and enabled Firefox’s tracking protection too.
