Emoji Confetti Render Issue in Firefox (on macOS)

[glmvc]

I was testing my website in Firefox (version 121.0) on macOS (Sonoma 14.2) and noticed that some emojis are rendering incorrectly in the canvas confetti (v1.9.2); please see the screenshot below.

The strange thing is that it only occurs with some emojis (e.g., "🦄" looks correct, "🍑" looks distorted when using the system ui font).

I found this issue where a similar (the same?) bug has already been fixed. But there still seems to be a problem...

Thank you for taking the time to review this issue.
Also, thanks for the great work!

[catdad]

Sigh... Firefox does seem to have a lot of issues with rendering fonts. This looks like it might be specific to using Apple's emoji font -- you can see that the initial unicorn is cut off rather than centered, that probably extends to the rest of the emojis as well.

I don't have a Mac right now, so it's gonna be a little difficult to debug this.

[glmvc]

Hi @catdad
Thanks for your reply. Ah, I see....

I'm working on macOS, but to be honest, I have no experience with such rendering and the OffscreenCanvas API...
Maybe one day I'll have time to dive deeper into this, but I can't promise anything.

Let me know if there is anything I can do to help you with this issue in the meantime.

[catdad]

Here's some high-level information if you or anyone else wants to investigate (most of it is probably too much information and maybe even wrong -- I've mostly figured this out myself because it's not well documented).

Text (emoji) is rendered to an image and then drawn using a CanvasPattern using a transform matrix. This part itself works fine. Firefox seems to have two problems:

• text measurements can be wonky. At first, I thought the issue was with the Twemoji font. It's possible it's actually with Firefox itself. Or maybe with my code. Or maybe an issue with Apple's font.
• when visible pixels touch the edge of the image, Firefox extends those pictures, drawing a "tail", when it applies the transformation matrix to the image pattern. This is just a Firefox bug.

The original workaround for the "tail" bug was to remove the Twemoji font (it's kinda ugly anyway, and shouldn't ever be a system default, it just seems to always be present in Firefox and the article I read said to use it) and to improve the text measurement code. This works with the Windows default Segoe font and Google's Noto font when added as a webfont. It also improved iOS rendering. Here is that same debug image rendered on other systems:

You can see that the emoji are centered in the yellow box, with extra transparent pixels around them. Firefox draws those correctly now (at least on the Windows system), and Chrome/Safar don't have the "tail" bug in the first place.

Of course, we could just make the image bigger, but a bigger image means slower performance. An alternative is to render the text to image and then add extra transparent pixels around it... if the image touches the edge, it will just get cut off and include an extra transparent buffer -- not ideal, but will probably work. The ideal situation is figuring out what is wrong with the text measurement and fixing it. The measurement code itself is here. Of course, all of this would have to be validated.

[glmvc]

Hello @catdad
I hope you're doing well.

Thanks for the input with the information on this particular issue.
I found time to look into it again when I suddenly noticed that with Firefox version 124 the bug seems to be resolved so far.

After doing a little research on this topic, I realized that the calculation with measureText() can be a real pain for cross-browser compatibility...

As shown in the screenshot below, Firefox still seems to get different values for the TextMetrics (actual bounding box height) with the Apple Emoji Font.
But at least there is no rendering problem anymore, since there is now free space between the emoji and the box in Firefox (as you already explained).

---

So, for my particular use case, the problem was (somehow) solved by the Firefox browser.

After a quick search, there seem to be some solutions (e.g., as you suggested, to render the text to an image...) for this kind of calculation differences.
However, I'll leave it up to you to decide whether this should be investigated further or whether you're satisfied with it for now.

I am happy to provide further assistance if you need more information regarding this matter in Firefox on macOS.