Add additional logging during the EmojiRepository plugin initialization

[dufipl]

📝 Provide a description of the improvement

We should add additional logging during the EmojiRepository plugin initialization since something might go wrong during the process related to emojis/fonts etc. Without this plugin being ready, the toolbar item and command are not registered and integrators will see the message that the toolbar item is unavailable without any further clue.

While integrating samples on CI that used Ubuntu images we encountered an issue with (as it occurred later) missing font and there were no logs that would help us to determine that was the case.

As we discussed with @pomek, it would be beneficial to add warnings at least if:

• there are no items
• there are no fonts
• the resource was not loaded

This will streamline debugging such kind of issues for integrators.

Definition of Done

• Display a warning if the EmojiRepository plugin returns an empty collection.
• Explain what happens - an HTTP error or the available emoji won't render on an integrator machine.
• Include a new section in the documentation. Troubleshooting. Let's explain why the feature filters emojis. If all of them are not supported, the feature does not initialize.

---

If you'd like to see this improvement implemented, add a 👍 reaction to this post.

[Bapawe]

Interesting! I've added the Emoji plugin to my dev project for testing. On my system, it works just fine, but a colleague encounters the following error in his browser console (across different browsers): toolbarview-item-unavailable: Object { item: "emoji" }

The only difference we’ve identified so far is that I’m using Windows 11, while my colleague is on Windows 10.

I'm using a local emoji dataset ("emoji-picker-element-data": "^1.7.1"): node_modules/emoji-picker-element-data/nl/cldr/data.json

Additionally, the issue persists when using the default dataset: https://cdn.ckeditor.com/ckeditor5/data/emoji/16/en.json.

Given this, how can I debug the problem to determine what’s causing it?

// edit
The Emoji example on https://ckeditor.com/docs/ckeditor5/latest/features/emoji.html has the same eror in console for my colleague on Windows 10

[pomek]

The emoji feature detects if the downloaded collection is supported on your machine. In other words, if the inserted emoji will be rendered correctly in the editable area (see #17834).

If you're sure that the network resource was downloaded correctly, there is no other way that missing Emoji font on the OS prevents the plugin from initializing the feature.

This was the case that @dufipl reproduced today, and spent time figuring out what and why it happens.

[pomek]

The Emoji example on ckeditor.com/docs/ckeditor5/latest/features/emoji.html has the same eror in console for my colleague on Windows 10

It confirms what I wrote, I think.

[Bapawe]

@pomek Okay, so if I understand correctly, the Emoji plugin doesn't work out of the box on Windows 10 because it's missing a required emoji font. To ensure both consistent appearance and availability, I'll need to install an external font like Noto Color Emoji, as mentioned in the documentation. Is that right?

[pomek]

@Bapawe, I hope installing a font will resolve your issue.

[Witoso]

@Bapawe also try to test the option with a lower unicode emoji version, it's possible that Windows 10 has a font, but a very old one. We host v15 and v16.

[Bapawe]

@Witoso I've tested both v15 and v16 without the definitionsUrl option, using the CKEditor 5 CDN. In both cases, the Emoji plugin fails to load, resulting in a toolbarview-item-unavailable: Object { item: "emoji" } error in the browser console.

Could this be a bug where the entire Emoji plugin isn't loaded on Windows 10, rather than just filtering out unsupported emojis?

[Witoso]

We are investigating, it's possible that the guardrails we put in place are too strict for the older systems.