Emojis in rich-text Connect macros not mapped correctly?

We have a static-content, rich-text Connect macro. When adding an emoji both to the normal body of a Fabric page and the macro body on the same page, at least one case is not rendered accurately inside the macro body. The implementation of this particular macro does nothing but return to Confluence the original SFXML posted to it, which Confluence then renders on the page. When the macro body SFXML is rendered by Confluence, the displayed emoji doesn’t match what was added in the editor.

The following screenshots depict the problem both inside and outside the macro body on a Fabric page. We were testing the lack of support for adding rich-text Connect macros to table cells (:disappointed:), which is where the demo text comes from.

Fabric editor:

Fabric published:

SFXML macro body posted to us by Confluence:

<p>unfortunately, the table wouldn’t let us put it in there <ac:emoticon ac:name=\"blue-star\" ac:emoji-shortname=\":disappointed:\" ac:emoji-id=\"1f61e\" ac:emoji-fallback=\"😞\" /> </p>

Rendered HTML inside Confluence:

Notice how the disappointed emoji was instead rendered as a blue star.

1 Like

It seems like emojis can also not be rendered by the convert content body REST API as seen in this post. (:disappointed:)

1 Like

Hi @BobBergman,

I had a go at reproducing this, but I’m not sure how. How do you generate the “disappointed” macro? The closest I see in Confluence Storage Format is the “sad” macro: <ac:emoticon ac:name="sad" />.

regards,
Dugald

I get this Storage Format when inserting the emoji by writing :disappointed: in a Confluence page:

1 Like

@dmorrow Sven beat me to it :slight_smile:

@sven.schatter We have experienced the same problem with the /contentbody/convert API, which is frustrating. In fact, there are a great many issues with the results of that API failing to handle various Confluence built-in structures and macros. We have built workarounds for some of them (such as applying JS for emojis that replace them with their fallback attribute values when we display that HTML in a Connect macro iframe), but in general the quality of output from that API is quite low :frowning: Its worsened by the fact that Confluence does not provide page content stylesheets on a CDN for Connect apps to leverage (and technically there ought to be one for each of the Legacy and Fabric page types). The Marketplace’s embeddable JSD/KB support widget for app listings seems to run into all the same problems, which makes me wonder why that API is so poorly supported.

1 Like

Thanks @BobBergman and @sven.schatter,

I’ve created https://jira.atlassian.com/browse/CONFCLOUD-69848 for this. Please let me know or comment on the issue if it doesn’t fully capture the problem.

Regards,
Dugald

3 Likes

@dmorrow Thanks for opening that!