When emoji appear as emoji reactions on messages, there are a couple of nuances to how we decide exactly what to show:
For image emoji we pick a still image instead of an animated one, where applicable, depending on a setting.
For image emoji we pass RealmContentNetworkImage.errorBuilder so that if the image doesn't load, we show the emoji's name as text.
For both Unicode and image emoji we check if the user has set Emojiset.text, and if so then we show the emoji's name as text instead of the glyph or image.
For details of these, see lib/widgets/emoji_reaction.dart.
When emoji appear in message content, however, we don't currently do any of the above.
I believe this discrepancy is only because the rendering of emoji in message content dates to the early prototype, when I was skipping over gnarly details of Zulip that didn't seem relevant to evaluating Flutter, while the rendering of emoji reactions was built (by @chrisbobbe) at a somewhat later stage. So we should add those same nuances to emoji in message content.
Filing this as a post-launch issue, though, because I don't think zulip-mobile handles any of these nuances. Also these are all fairly unusual situations and I don't think we've heard any users mention them — I noticed the discrepancy only through working on the code, for #669.
When emoji appear as emoji reactions on messages, there are a couple of nuances to how we decide exactly what to show:
RealmContentNetworkImage.errorBuilderso that if the image doesn't load, we show the emoji's name as text.Emojiset.text, and if so then we show the emoji's name as text instead of the glyph or image.For details of these, see
lib/widgets/emoji_reaction.dart.When emoji appear in message content, however, we don't currently do any of the above.
I believe this discrepancy is only because the rendering of emoji in message content dates to the early prototype, when I was skipping over gnarly details of Zulip that didn't seem relevant to evaluating Flutter, while the rendering of emoji reactions was built (by @chrisbobbe) at a somewhat later stage. So we should add those same nuances to emoji in message content.
Filing this as a post-launch issue, though, because I don't think zulip-mobile handles any of these nuances. Also these are all fairly unusual situations and I don't think we've heard any users mention them — I noticed the discrepancy only through working on the code, for #669.