Gutenberg 3.8 - 4.1.1 Paragraph Block Thinks Modified Externally if an Emoji Is Used.

[MarkRH]

Describe the bug
With WordPress 3.9.8 and Gutenberg 3.80, if I paste an emoji into a paragraph block and save the post, when I go to re-edit it, it thinks it has been modified externally. If I click convert to blocks it goes back to the way it was with the emoji still there.

To Reproduce
Steps to reproduce the behavior:

1. Add an emoji to a paragraph block, like 🙁
2. Save or Publish the post
3. Edit the same post.
4. Thinks block was edited externally.

Expected behavior
It should not think it was modified externally.

Screenshots

Desktop (please complete the following information):

• OS: Windows 7 Pro 64bit
• Browser: Firefox 62

Additional context
In my case, it looks like the emoji is stored in the database as 🙁 which might be why it's being triggered?

[aduth]

I'm having trouble reproducing this. Could you provide more information on whether there's anything about your site or user which could have an impact here? Specific plugins on the site? User role?

[MarkRH]

Same thing happens if I deactivate all plugins except Gutenberg, so that should rule out a plugin conflict? I am using a Twenty Twelve child theme.

Also happens on my local PC as well as my webhost. My user role is whatever the highest admin role is.

The database table field is defined as:
post_content longtext utf8_general_ci

[pento]

Thanks for the bug report, @MarkRH!

For anyone wanting to reproduce this bug in the Gutenberg Docker environment, run this command:

docker-compose run --rm mysql mysql -u root -pexample -h mysql --protocol=tcp wordpress -e "SET SESSION sql_mode='ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'; ALTER TABLE wp_posts MODIFY post_content LONGTEXT CHARACTER SET utf8"

Then the steps in the original report will work.

[aduth]

Is it fair to say that for validation purposes, we should normalize the HTML-encoded form 🙁 as equivalent to the emoji 🙁?

var d = document.createElement( 'div' );
d.innerHTML = '🙁'
d.textContent
// "🙁"

Edit: In case its unclear, I don't mean we should hardcode normalization of this single emoji, but between encoded forms and emojis generally.

[pento]

Yup, I think that's a reasonable way to do this.

[MarkRH]

Gutenberg 3.90. Same thing, but I expected that as no mention in the change log.

[aduth]

Another instance raised in Slack, specifically relating to export / import flows (link requires registration):

https://wordpress.slack.com/archives/C02QB2JS7/p1539622489000100

[MarkRH]

Gutenberg 4.0.0, same issue. Slightly different warning message:

So it wants me to convert to HTML or back into blocks:

[MarkRH]

Same happens with 4.1.1, even if I save as a Custom HTML Block, it thinks it was still modified externally when I go back.

[MarkRH]

With Gutenberg 4.3.0 when I go to edit a post that had an emoji in it (created with previous version), I still get the message and when I click resolve or convert to HTML the editor does nothing. Still on WP 4.9.8.

[aduth]

The proposed pull request at #11771 is slated to resolve this.