WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#31843 closed defect (bug) (invalid)

Emoji inserted in Visual tab is not the one you click

Reported by: eliorivero Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.2
Component: Editor Keywords:
Focuses: Cc:
PR Number:

Description

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.

Change History (6)

#1 @strider72
5 years ago

[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)

Last edited 5 years ago by strider72 (previous) (diff)

#2 @strider72
5 years ago

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.

Last edited 5 years ago by strider72 (previous) (diff)

#3 @eliorivero
5 years ago

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.

#4 follow-up: @kraftbj
5 years ago

  • Resolution set to invalid
  • Status changed from new to closed

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.

#5 @kraftbj
5 years ago

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.

#6 in reply to: ↑ 4 @SergeyBiryukov
5 years ago

  • Milestone Awaiting Review deleted

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

Note: See TracTickets for help on using tickets.