Closed
Bug 1089787
Opened 10 years ago
Closed 10 years ago
Emoji characters in textarea no longer have spaces between them
Categories
(Core :: DOM: Editor, defect)
Core
DOM: Editor
Tracking
()
RESOLVED
FIXED
mozilla36
Tracking | Status | |
---|---|---|
firefox33 | --- | unaffected |
firefox34 | --- | unaffected |
firefox35 | --- | affected |
firefox36 | --- | fixed |
People
(Reporter: cpeterson, Assigned: jfkthame)
References
Details
(Keywords: regression, reproducible)
Attachments
(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: 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•10 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.
Reporter | ||
Comment 3•10 years ago
|
||
Reporter | ||
Comment 4•10 years ago
|
||
Assignee | ||
Comment 5•10 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•10 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•10 years ago
|
||
Attachment #8519410 -
Flags: review?(jdaggett)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Assignee | ||
Comment 8•10 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•10 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•10 years ago
|
||
Rebased following jwatt's gfxContext/DrawTarget parameter replacements.
Attachment #8520600 -
Flags: review?(jdaggett)
Assignee | ||
Updated•10 years ago
|
Attachment #8519410 -
Attachment is obsolete: true
Attachment #8519410 -
Flags: review?(jdaggett)
Comment 11•10 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+
Assignee | ||
Comment 12•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/e98e2ac200a6
Target Milestone: --- → mozilla36
Comment 13•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/e98e2ac200a6
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Updated•10 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•