Emoji characters in textarea no longer have spaces between them

RESOLVED FIXED in Firefox 36

Status

()

Core
Editor
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: cpeterson, Assigned: jfkthame)

Tracking

({regression, reproducible})

unspecified
mozilla36
regression, reproducible
Points:
---

Firefox Tracking Flags

(firefox33 unaffected, firefox34 unaffected, firefox35 affected, firefox36 fixed)

Details

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

4 years ago
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:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=2311039e076b&tochange=d0be07d7cf1b

[Tracking Requested - why for this release]:
This is a visual regression in Firefox 35.
Flags: needinfo?(hsivonen)
Weird. The only layout-relevant change is https://hg.mozilla.org/integration/mozilla-inbound/diff/d0be07d7cf1b/dom/encoding/encodingsgroups.properties but it's not supposed to matter to Twitter.
(Reporter)

Comment 2

4 years ago
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:

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=998a7adb3d9c&tochange=371c154c2e9d

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
(Reporter)

Comment 3

4 years ago
Created attachment 8519386 [details]
good-HiDPI-display-has-spaces.png
(Reporter)

Comment 4

4 years ago
Created attachment 8519387 [details]
bad-External-display-has-no-spaces.png
(Assignee)

Comment 5

4 years ago
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)
(Assignee)

Comment 6

4 years ago
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)

Comment 7

4 years ago
Created attachment 8519410 [details] [diff] [review]
Get glyph widths via Core Text for fonts with embedded color bitmaps.
Attachment #8519410 - Flags: review?(jdaggett)
(Assignee)

Updated

4 years ago
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
(Assignee)

Comment 8

4 years ago
Try run with this patch: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=24f4ceaf0548.

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.
(Reporter)

Comment 9

4 years ago
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+
(Assignee)

Comment 10

4 years ago
Created attachment 8520600 [details] [diff] [review]
Get glyph widths via Core Text for fonts with embedded color bitmaps.

Rebased following jwatt's gfxContext/DrawTarget parameter replacements.
Attachment #8520600 - Flags: review?(jdaggett)
(Assignee)

Updated

4 years ago
Attachment #8519410 - Attachment is obsolete: true
Attachment #8519410 - Flags: review?(jdaggett)

Comment 11

4 years ago
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+
https://hg.mozilla.org/mozilla-central/rev/e98e2ac200a6
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
status-firefox36: affected → fixed
You need to log in before you can comment on or make changes to this bug.