Closed Bug 1089787 Opened 5 years ago Closed 5 years ago

Emoji characters in textarea no longer have spaces between them


(Core :: DOM: Editor, defect)

Not set



Tracking Status
firefox33 --- unaffected
firefox34 --- unaffected
firefox35 --- affected
firefox36 --- fixed


(Reporter: cpeterson, Assigned: jfkthame)



(Keywords: regression, reproducible)


(3 files, 1 obsolete file)

When verifying bug 1068530, I noticed that the emoji characters no longer have spaces between them. This problem more readily apparent on my non-HiDPI external display than my MBP's internal HiDPI/Retina display). When I backspace to delete the emoji characters, they sometimes leave gfx artifacts between the characters.

This only seems happens in Twitter's "Compose new Tweet..." text field, not the "Search Twitter" text field. See the attached screenshots.

hsivonen: I bisected this regression to your HZ-GB-2312 changesets on Nightly 35 build 2014-09-26, but I'm going to guess bug 964225:

[Tracking Requested - why for this release]:
This is a visual regression in Firefox 35.
Flags: needinfo?(hsivonen)
Weird. The only layout-relevant change is but it's not supposed to matter to Twitter.
Sorry, my bisection was incorrect because I missed an important step of my STR. I correctly bisected this regression to Jonathan's fix for bug 923007:

The missing step is that the bug only shows up on my external display, not my Retina/HiDPI MacBook Pro's internal display. When the browser window is on the MacBook Pro's internal display, there is the expected space between the emoji characters. When I drag the same window to the external display, the space is gone.

Also, the bug is not specific to Twitter. I see the same problem with emoji characters in this Bugzilla comment textarea. See the attached screenshots.
Blocks: 923007
No longer blocks: 964225
Flags: needinfo?(hsivonen) → needinfo?(jfkthame)
Summary: Emoji characters in Twitter's "Compose new Tweet" field do not have spaces between them (after Firefox's HZ-GB-2312 support was removed) → Emoji characters in textarea no longer have spaces between them
Weird. This looks just like bug 804934, but we thought that was resolved. It's dependent on the (device pixel) size at which the emoji font is being used; if you zoom in sufficiently on your external display, so that the font size becomes larger, you'll see the glyphs begin to separate properly. And conversely, if you set gfx.hidpi.enabled to zero, so that we run at low resolution even on the retina display, you'll see the problem there as well.

I don't currently understand why the fix for bug 923007 should have caused this to reappear, though.
Flags: needinfo?(jfkthame)
OK, the issue here is that we assume glyph widths are scaled linearly on OS X, and so allow harfbuzz to use widths derived directly from the 'hmtx' table. This is normally true, but it does not hold when Core Text is rendering color emoji bitmap glyphs at small pixel sizes: it appears to render with non-linear scaling, and so we need to get the corresponding glyph widths through Core Text APIs as well.
Assignee: nobody → jfkthame
Try run with this patch:

Chris, if you'd like to test this build and confirm whether it fixes the issues you've been seeing, that'd be great - thanks.
Comment on attachment 8519410 [details] [diff] [review]
Get glyph widths via Core Text for fonts with embedded color bitmaps.

The emoji spacing in the Try build looks good!
Attachment #8519410 - Flags: feedback+
Rebased following jwatt's gfxContext/DrawTarget parameter replacements.
Attachment #8520600 - Flags: review?(jdaggett)
Attachment #8519410 - Attachment is obsolete: true
Attachment #8519410 - Flags: review?(jdaggett)
Comment on attachment 8520600 [details] [diff] [review]
Get glyph widths via Core Text for fonts with embedded color bitmaps.

Review of attachment 8520600 [details] [diff] [review]:

r+ with warning.

::: gfx/thebes/gfxMacFont.cpp
@@ +373,5 @@
> +        mCTFont = ::CTFontCreateWithGraphicsFont(mCGFont, mAdjustedSize,
> +                                                 nullptr, nullptr);
> +        if (!mCTFont) { // shouldn't happen, but let's be safe
> +            return 0;
> +        }

I think a warning would be useful here.
Attachment #8520600 - Flags: review?(jdaggett) → review+
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.