Closed Bug 1495400 Opened 2 years ago Closed 2 years ago

Emoji larger than 98px are not displayed


(Core :: Graphics: Text, defect, P3)

62 Branch



Tracking Status
firefox68 --- fixed


(Reporter: tobi, Assigned: lsalzman)



(1 file)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180920131237
Firefox for Android

Steps to reproduce:

in Mobile Firefox 62.

At font-size 98px, the emoji are shown:

in Mobile Firefox 62.

Actual results:

At font-size 99px, the emoji are not shown:

Expected results:

The emoji should be displayed up to font-sizes of 146px (the limit of Mobile Chrome 69) or larger if possible.

Also see
Component: Untriaged → General
Product: Firefox → Firefox for Android
Version: 62 Branch → Firefox 62
Confirmed with Firefox 64.0a1 on a Nexus 5x running Android 8.1.0
Component: General → Graphics: Text
Ever confirmed: true
OS: Unspecified → Android
Product: Firefox for Android → Core
Hardware: Unspecified → All
Summary: Maximum font size for emoji in mobile Firefox is too small → Emoji larger than 98px are not displayed
Version: Firefox 62 → 62 Branch
Confirmed on a recent 64.0a1 GeckoView Example build as well.
Priority: -- → P3

I hope this issue can get fixed.

Jamie, can you look into this? My guess is this is an issue with the Skia font size limits, though I don't have an Android dev environment set up at the moment to investigate myself...

Flags: needinfo?(jnicol)

I list some data at , I'd be happy to update the info regarding Mobile Firefox as soon as it supports larger emoji.

Lee I'm really lost for where to even start looking for this, don't know the skia code at all. Do you have any pointers?

Flags: needinfo?(jnicol) → needinfo?(lsalzman)

(In reply to Jamie Nicol [:jnicol] from comment #6)

Lee I'm really lost for where to even start looking for this, don't know the skia code at all. Do you have any pointers?

First try and verify that the FillGlyphs call is getting to the DrawTargetSkia, and if so, find out where the request is getting short-circuited inside Skia.

Flags: needinfo?(lsalzman)

The code paths for 98px and 99px emoji diverge in SkGlyphRunListPainter::drawForBitmapDevice. For smaller than 98px ShouldDrawAsPath() returns false and we use drawUsingMasks(), which succeeds. For larger than 99px ShouldDrawAsPath() returns true and we use drawUsingPath() which fails.

drawUsingPath() fails in SkScalerContext_CairoFT::generatePath(), where the call to mozilla_LoadFTGlyph (which calls FT_Load_Glyph) fails. I couldn't trace the code any further in to FT_Load_Glyph unfortunately. The return value is 0x24 "Invalid Size Handle", not sure what that means. If I remove the FT_LOAD_NO_BITMAP flag from that call, then the call succeeds, but we still fail somewhere to render anything.

In ShouldDrawAsPath(), there's a call to SkTypeface::hasColorGlyphs(), which if true forces us not to use paths. But on android (and all platforms other than mac by the looks of it) this simply returns false all of the time.

Interestingly, on desktop linux, even when drawing as a path the emojis are rendered absolutely fine. My hunch is that the emoji implementation on Linux is vector-based can be rendered using paths, but emojis on Android (and Mac) are bitmaps so cannot. Does that make sense Lee?

If that is correct, then the solution would be to override SkTypeface::hasColorGlyphs on android to return something sensible rather than always false?

Flags: needinfo?(lsalzman)
Flags: needinfo?(lsalzman)
Assignee: nobody → lsalzman
Pushed by
don't draw non-scalable FT faces as paths. r=jnicol
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68


You need to log in before you can comment on or make changes to this bug.