[Bug] AppImage crashes when rendering COLRv1 emoji fonts on Fedora

[tnull]

Description

On Fedora with Wayland/Hyprland, the Buzz AppImage opens as a blank, transparent window and then aborts while rendering an emoji.

Error

././/include/c++/12/bits/stl_vector.h:1123: constexpr std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator [with _Tp = {anonymous}::colrv1_configure_skpaint(FT_Face, const SkSpan&, SkColor, const FT_COLR_Paint&, SkPaint*)::<lambda(const FT_ColorStopIterator&, std::vector&, std::vector<SkRGBA4f<kUnpremul_SkAlphaType> >&)>::ColorStop; _Alloc = std::allocator<{anonymous}::colrv1_configure_skpaint(FT_Face, const SkSpan&, SkColor, const FT_COLR_Paint&, SkPaint*)::<lambda(const FT_ColorStopIterator&, std::vector&, std::vector<SkRGBA4f<kUnpremul_SkAlphaType> >&)>::ColorStop>; reference = {anonymous}::colrv1_configure_skpaint(FT_Face, const SkSpan&, SkColor, const FT_COLR_Paint&, SkPaint*)::<lambda(const FT_ColorStopIterator&, std::vector&, std::vector<SkRGBA4f<kUnpremul_SkAlphaType> >&)>::ColorStop&; size_type = long unsigned int]: Assertion '__n < this->size()' failed.

This appears to be triggered when WebKitGTK/Skia renders Fedora's COLRv1 Noto Color Emoji font. The same crash has been reported in other WebKitGTK-based AppImages: farion1231/cc-switch#2176

Reproduction

1. Run the Buzz AppImage on Fedora under Wayland/Hyprland.
2. Open a view containing emoji, or allow the initial UI to render.
3. The window remains blank/transparent and the process aborts with the
   assertion above.

Workaround

A Fontconfig override that prevents Buzz from using the system color emoji font avoids the crash.

Suggested fix

Bundle and preload a non-COLRv1 emoji font in the desktop application before React renders, and place it ahead of generic font fallbacks. Native Apple and Segoe emoji fonts could remain preferred on macOS and Windows.

Environment

• Buzz: v0.4.23 AppImage
• Distribution: Fedora
• Display server: Wayland
• Compositor: Hyprland

[Chessing234]

Fix in #2689: AppImage fontconfig rejects Noto Color Emoji.

[FredericoTMello]

Also confirmed on Fedora 44 + GNOME + Buzz 0.4.26 AppImage with the same colrv1_configure_skpaint abort (host FreeType 2.14 / HarfBuzz 14 + Noto-COLRv1.ttf).

Detailed reproduction and environment notes posted on the more complete report: #2982 (comment: #2982 (comment)).

[wpfleger96]

🤖 Thanks for the detailed report — the backtrace pointed us straight at the root cause.

This was a FreeType ABI mismatch: the AppImage was built on Ubuntu 22.04, so WebKit/Skia's COLRv1 code was compiled against FreeType 2.11 headers, but Fedora 40+ ships FreeType 2.13 where the FT_ColorStopIterator struct layout changed. The AppImage uses the host's FreeType at runtime, so rendering a color emoji walked off the end of the color-stop vector and hit that assertion.

The fix was moving the Linux build to Ubuntu 24.04 (#3602), so the bundled WebKitGTK (now 2.52.3) is compiled against FreeType 2.13 and matches modern hosts. This shipped in v0.5.2 — upgrading the AppImage should resolve the crash.

Two notes: the new build raises the glibc floor to 2.39 (fine on Fedora 40+; Ubuntu 22.04 / Debian 12 users should take the .deb), and if you're stuck on an older AppImage there's a manual fontconfig workaround in docs/linux-rendering-troubleshooting.md.

Closing as fixed in v0.5.2 — please reopen if the new build still crashes for you.