[wp-trac] [WordPress Trac] #61806: twemoji is always loaded on Windows devices

WordPress Trac noreply at wordpress.org
Wed Aug 14 15:47:57 UTC 2024


#61806: twemoji is always loaded on Windows devices
--------------------------+------------------------------
 Reporter:  Clorith       |       Owner:  pbearne
     Type:  defect (bug)  |      Status:  accepted
 Priority:  normal        |   Milestone:  Awaiting Review
Component:  Emoji         |     Version:
 Severity:  minor         |  Resolution:
 Keywords:                |     Focuses:  performance
--------------------------+------------------------------

Comment (by Clorith):

 The three emojis at the end of your message are indeed showing as a
 blackbird, then a red bird with a black square following it, but they're
 also all replaced by the `img` tags.

 You are correct that it seems like it is incorrectly detecting that emojis
 can not be displayed, and that there are two issues reported here;

 Incorrect detection of valid emoji support, leading to the triggering of
 the image conversion (which then loads assets from the WordPress CDN,
 `s.w.org`), adding additional networ ktraffic when it isn't actually
 needed.

 And that the front-end and back-end of WordPress is not both enqueuing
 (and thus ensuring support for) emojis on the same basis, as the editor
 screen seems to intentionally dequeue it? This may very well be a twemoji
 issue in terms of Windows support though, but for the 2nd issue, it would
 ideally have the same emoji and visuals in the back-end and front-end. As
 you noted, perhaps this is relating to rendering vs editorial mode
 differences, although I was not aware that was a thing, but if it is a
 thing, then surely when a block is not in edit mode, it would be in
 display mode, and render the same as the front-end viewing? (this may be a
 deeper question for the block editor maintainers I guess?)

 In an ideal scenario, the twemoji script would look up any emoji used on a
 page, and only replace the ones not supported (this may need reporting
 upstream to see if it's even viable?) So let's focus on that first and
 foremost, and then the editor side of it can be a separate ticket, to not
 muddy the waters too much :)

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/61806#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list