Wp-calypso: Gutenberg: Post Content Lost After Editing Image in Media Modal

[Aurorum]

Steps to reproduce

1. Starting at URL: https://wordpress.com/block-editor/post/
2. Add a title, add some text
3. Add an Image Block
4. Select Media Library
5. Click an image
6. Select "Edit"
7. Select "Edit Image"
8. Click "Cancel" or "Done"
9. Insert
10. Post content lost

What I expected

I'd return to the post with the new image.

What happened instead

All post content was wiped.

Browser / OS version

Chrome 75 on macOS

Context / Source

Accidentally came upon whilst writing a post. :)

[ivan-ottinger]

Another report #2162007-zen

I think this is quite serious bug - as it basically deletes the content user created prior. It's a disaster if the post hasn't been autosaved.

[tanjoymor]

Another case: #13648781-hc

I agree with Ivan... this is a pretty serious issue.

I'm wondering how often this is the actual culprit when we have a user contact us about their post content mysteriously going missing?

With this particular user, if I hadn't already been aware of this issue, I never would have thought to even ask the question of "did you happen to insert and edit image right before the content went missing?" (and the answer was yes).

[tanjoymor]

This is a video that shows how the image itself won't insert after editing it:

https://monosnap.com/file/Uvl17d7Q5QKdeqRUxv6EhD0cZusn0H

And this video demonstrates how the content goes missing if you add/edit an image before an autosave/save has been performed:

https://monosnap.com/file/CICMElrhsYmpViwySJdUzCMVS5ZwLS

[tanjoymor]

Have also confirmed that it doesn't happen in wp-admin because the interface is different. When you're inserting images through wp-admin the edit button is on the right and opens in a new window rather than in the iframe.

[glendaviesnz]

Have been able to replicate this on a local calypso dev instance using the above steps.

Additional notes:

• It is not necessary to actually edit the image in the image editor window - just opening the editor window and clicking done, or cancel, replicates the bug
• On a new post all content is lost, but on an existing post any new content added after openining the post to edit is wiped - existing saved content remains
• There are no console errors after clicking on Insert
• In some instances, if you try adding an image block again after the content has been wiped you are presented with the wp-admin media library dialog that opens the Edit Image dialog in a new tab

[xpurichan]

I had another report in 2174695-zd. I had actually opened a new bug report about it here, but closed it after being notified of this one. My old report:

https://github.com/Automattic/wp-calypso/issues/34665

[glendaviesnz]

After a bit more debugging I have narrowed down the issue to the loading of the Edit Image dialog. The post content is actually wiped as soon as the Edit Image dialog is opened, not on the clicking of the Insert button.

Opening the Edit image dialog causes two re-renders of the CalypsoifyIframe component - on the second re-render the editor content is wiped. For some reason this.prop.shouldLoadIframe gets set to false during one of the re-renders which causes the content loss - forcing shouldLoadIframe to always be true prevents the data loss - will try and work out why this is being set to false in the instance of the edit image modal tomorrow, unless someone else has time to pick this up in the mean time.

[glendaviesnz]

So the exact cause of the issues is that at https://github.com/Automattic/wp-calypso/blob/master/client/gutenberg/editor/calypsoify-iframe.tsx#L575 isRequestingSite( state, siteId ) returns true when the image edit dialog loads, which sets shouldLoadIframe to false, and this causes a reload of the iframe and the loss of content.

Now just need to work out how to stop this happening.

[aisajib]

Just had a user report this problem to us at 10118046-hc. They said the problem started about two weeks ago.

I've offered to follow up with them when this is fixed.

[glendaviesnz]

Just pushed an update to production which should fix this issue in both WP.com Simple Sites and JetPack sites.