Emoji inserted in Visual tab is not the one you click

[eliorivero]

Using 4.2-beta3-31945 in Chrome 41.0.2272.104 (64-bit) in OS X 10.10.2 (14C1514)

The emoji inserted in Visual tab is not the clicked one. The one clicked can be found in Text tab. Recorded a mini video of this:

​http://queryloop.com/wp-content/uploads/emoji.m4v

Not sure if this is the default behaviour, but it's certainly confusing to click an icon and insert another.

[strider72]

[EDIT: I see what you're saying. Nonetheless, despite your own browser, you should not expect emoji to appear the same on different devices. OS X uses one set of images, Windows another, and so forth.]

Emoji are kind of like fonts -- they vary from OS to OS and device to device. You'll note you clicked a horse and you got a horse -- it's just a different image.

The popup was provided by the Mac OS. The image that appeared in the text window must have come from somewhere else... perhaps the browser??? But in the end I don't believe this is a WordPress bug -- it's something particular to your setup.

(Note: When I copy your video, I get the same image as the one I click. That's using Firefox 36.04 on Mac OS 10.10.2)

[strider72]

Interesting. I tried to type the same horse symbol as an example, but the Trac system removes anything coming after the emoji from what gets posted.

[eliorivero]

Please note that I added the browser because that's where the issue occurs.

I also get the correct emoji when I click on it in Safari 8.0.4.

[kraftbj]

Chrome notably lacked emoji support until recently (M41) and still has quirks, namely with regards to not rendering if the font weight is over 500.

The Horse that is rendering for you is from the ​Twitter's open-source emoji set, which is what WP is using when the browser/OS combo doesn't support emoji or we otherwise have a reason to think it doesn't.

You can confirm this is what is occurring by inspecting the element of the editor after the change and see that it is actually an image file being served by WP.

I'm not certain, but I'd suspect that Trac's db schema doesn't support emoji (four-byte unicode), hence why it drops.

Marking it as invalid as this is how WP's emoji support is designed to work—supplementing the browser/OS's emoji support.

[kraftbj]

Noting that when you save an emoji that was enhanced with an image, like your horse, it is saved in the database as an actual emoji character, so it will be rendered directly by the browser/OS when it is supported or as an image when the browser does not.

[SergeyBiryukov]

Replying to kraftbj:

I'm not certain, but I'd suspect that Trac's db schema doesn't support emoji (four-byte unicode), hence why it drops.

Related: ​#meta386