Closed Bug 1160453 Opened 9 years ago Closed 8 years ago

Facebook-emojis are cut off in text-input-field, on Windows only, due to dependence on font metrics of ideographic space (U+3000)


(Web Compatibility :: Site Reports, defect)

Windows 7
Not set


(platform-rel ?)

Tracking Status
platform-rel --- ?


(Reporter: elbart, Unassigned)




(Keywords: top100, Whiteboard: [sitewait] [font][platform-rel-Facebook])


(3 files)

Attached image fb.png
When writing a message in Facebook, emoticons like ':(' are automatically replaced by the respective icon.

In Firefox on Windows, these icons are cut off on the side.
Disabling HWA or using safemode don't help.

In Chrome and IE they're fine, also in Firefox on Ubuntu.
Is this a regression? (I don't see it on mac).
(In reply to Timothy Nikkel (:tn) from comment #1)
> Is this a regression? (I don't see it on mac).
First Nightly I can reproduce it in is 2012-06-05.

Last good revision: dd6ec482a85d (2012-06-04)
First bad revision: a7a905fd70d5 (2012-06-05)
Nothing in that range stands out.

I can reproduce the problem on Windows though.
Ever confirmed: true
(In reply to Timothy Nikkel (:tn) from comment #3)
> Nothing in that range stands out.
Not regarding the underlying bug, but in that range is the change which made the bug "work" with Facebook.

Before that Nightly, the automatic replacement of the emoticon doesn't work for me. Maybe 
> Bug 727834 - Add an API to (re)parse a style sheet in place. r=bz
Ah. That makes sense then.

It seems likely that a change to facebook is involved (either triggering a firefox bug, or a problem in facebbok).

I think a reduced testcase might be useful.
I've managed to reproduce this on the latest release(44.0.2) and latest Nightly(47.0a1).

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160211075855

The test case is very simple:
1. go to Facebook and comment on a photo
2. input an emoticon, e.g. ;)
3. press space and input another emoticon(or the same one), e.g. ;) ;)
4. see how the emoticon icon is cut out(as seen in the reporter's attachment)
So I think this is a Facebook bug.  They're making assumptions about the sizes of an ideographic space (U+3000) in the current font, and constructing the emoji character as the background on a span (with padding) around an ideographic space.  This ends up depending on what font we pick to display the ideographic space.

They'd be better off using display:inline-block and just setting the size they want.

The CSS being sent is slightly different to Linux vs. Windows Firefox, but I don't think the CSS differences actually matter (I think they're related to using different icon sets for different platforms, and some of those icon sets supporting High DPI displays.)
This happens to be simplified from the Linux CSS, but shows the bug on Windows.
Attachment #8719009 - Attachment description: simple testcase → simple testcase (from Facebook's Linux icon set)
Summary: Facebook-emojis are cut off in text-input-field → Facebook-emojis are cut off in text-input-field, on Windows only, due to dependence on font metrics of ideographic space (U+3000)
I'm going to move this to Tech Evangelism; hopefully we can find some contacts at Facebook who are willing to look into this.

For what it's worth, on Facebook Linux I see a pixel shaved off the top of the emoticon -- although I don't actually see that in the simplified testcase.  This is probably because I simplified the testcase too much to show that problem, since I stripped out the containing div that has overflow-x:hidden; overflow-y:auto.  But the problem on Windows with a substantial number of pixels shaved off the right is much more visible.

I think fixing this by using display:inline-block ought to be relatively straightforward on their end (particularly given that they're already using vertical-align: bottom, which means they're not worrying about baseline alignment), and they can then probably avoid using an ideographic space (which might slow things down by triggering additional font loads).
Component: Layout → Desktop
Product: Core → Tech Evangelism
Version: unspecified → Trunk
(And on my Windows 10 laptop, the font used for the ideographic space is "MS PGothic".)
And, to be clear, my suggested fix was:
 * change display:inline on the span for the emoji to display:inline-block
 * set the height and width of that inline-block explicitly, and drop the padding (but keep vertical-align: bottom)
 * drop the ideographic space character (and perhaps also the extra spans inside of the emoji span)

Then again, it occurs to me that it may well be done the way it is now rather than with display:inline-block because there will be editing issues with cursor movement/positioning or backspace/delete when using inline-block.  In fact, if I implement my suggested fix by messing with the CSS in inspector, I do see a caret positioning issue when backspacing across the emoji (the caret overlaps the emoji when it should be at the right edge of it) or when right-arrowing across it.

So it's probably not that trivial to fix...
Contacted Facebook by email through our shared list.
Whiteboard: [sitewait] [font]
An alternative fix might be to use a downloadable font (with known metrics) for that ideographic space character.
Whiteboard: [sitewait] [font] → [sitewait] [font][platform-rel-Facebook]
platform-rel: --- → ?
I tested using the latest aurora (Fx 52.0a2, ID: 20161116004016) on Windows 10 x64, Windows 7 x64, Ubuntu 14.04 LTS  and  Mac OS X 10.11 and the emoji/emote icon in the comment section after a space becomes blank. However after the comment is posted, the icon/emoji is properly displayed.

The same regression range as in comment 2. The behavior of this issue may have changed.
The bug is not reproducible anymore on 51.0.1 build3 using Ubuntu 14.04 x86, Mac OS X 10.11, Windows 10 x64 and Windows 7 x64.
Thanks Iulia, let's close this as FIXED.
Closed: 8 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.