Able to reproduce this issue on reported version 62.0.3202.62 , on latest canary 64.0.3247.0 using Mac 10.12.6 with given sample JSFiddle link.

This issue is seen from M50 i.e; 50.0.2661.0. Hence considering this issue as Non-regression and marking as Untriaged.

NOTE: Issue is not seen in Linux and Windows

let's save all the emojis.

Dominik, two things happening here.

1. width is returning the font size, which at bigger sizes seem fine, but at lower sizes are smaller than the actual emoji.
2. related to this, the new bounding box calculation is returning 0 for ascent/descent.

Investigating.

For the width, http://crbug.com/596223 is the culprit. I'll keep bug open to investigate the height issue and the dup it on the older one.

Good thing is, for the width, there's a solution being worked on.

drott:

for Ascent/Descent, it seems that on GetSkiaBoundsForGlyph() getTextPath is returning 0,0,0,0 while getTextWidths returns sort of reasonable values. Is there a reason for getTextPath to not work at all for emojis?

That said, the returning value on getTextWidths there seems to overshoot the bounds (by a couple pixels), which I assume is due to https://bugs.chromium.org/p/skia/issues/detail?id=5328.

Do you think it would be reasonable to, when getTextPath returns 0 to fallback to textWidth, even with the current mac bug?

Also, there's something else going on when I start using getTextWidths(), I get for the 12px smile emoji, the following bounds: left/right: -1, 16, ascent/descent: 14,4.

But If I make GetSkiaBoundsForGlyph return that, the from_x, to_x on GetCharacterRangeInternal still goes to 0,12, BUT if there I calculate based on the x/maxx bounds I end up with -1,16 (which is correct). I'm guessing it has to do with the advance width being used, but I'm not sure. Do you have any idea for this?

This means that the selection range for the emoji should be wrong on mac (not only for canvas). And I tested that. If you zoom out the emoji on this bug report and select, the selection stops before the emoji. o_O.

Where is the width issue being worked on? I noticed something similar with two adjacent emojis.

Interestingly enough (as in https://crbug.com/596223) the effect is more pronounced on a non-retina screen attached to a mac.

Deleted: Screen Shot 2018-01-02 at 19.20.08.png 5.8 KB

	Screen Shot 2018-01-02 at 19.20.08.png 5.8 KB View Download

Deleted: Screen Shot 2018-01-02 at 19.20.17.png 8.1 KB

	Screen Shot 2018-01-02 at 19.20.17.png 8.1 KB View Download

Deleted: Screen Shot 2018-01-02 at 19.21.43.png 6.0 KB

	Screen Shot 2018-01-02 at 19.21.43.png 6.0 KB View Download

Re #8, yes, the bounds situation on Mac is not optimal. getTextWidths is not fully suitable for our layout purposes, and getTextPaths does not work for emoji since Skia tries to retrieve a contour/outline and measure it, which is impossible for a bitmap font. The underlying problem is that there are different bounds. Skia needs bounds that "cover all pixels of a glyph", which for contour fonts is not necessarily identical to what we want for layout: There we want the TrueType glyph bounding box for fonts with a glyf table, which can be 1 or 2 pixels smaller. For Emoji fonts we want the size of the bitmap and correct tracking, which is hard to get right due to lack of CoreText API for setting up tracking correctly.


The solution is either to continue to work with the Skia team on trying to improve that, or in the worst case, implement our own metrics on Mac.

Unfortunately, I currently do not have time to follow up on this issue. I've continuously tried but my success in driving this issue with the Skia team has been limited.

This seems to be fixed now (though unfortunately, the opposite is now true! https://bugs.chromium.org/p/chromium/issues/detail?id=816978 )

davidqu@chromium.org hasn't logged in in more than 30 days, so this bug showed up in the triage queue.

The specific issue with measureText seems to not be present anymore. A similar bug remains, but it is tracked here: https://crbug.com/816978
Closing this one to avoid duplicate efforts.