Code Editor: Content changes not respected when using mode change keyboard shortcut

[aduth]

Describe the bug

When making a change to the post content in the Code Editor and retaining focus within the Code Editor's textarea, switching back to Visual Editor reveals that the changes were not applied if the change in editor modes is applied using the keyboard shortcut.

To Reproduce

1. Navigate to Posts > Add New
2. (Prerequisite) Switch to Code Editor if not already
3. Enter text in the Code Editor textarea
4. Without leaving the field, press the keyboard combination to switch editor modes (⇧⌥⌘M)
5. Note that your changes made in Step 3 are not shown.

Expected behavior

Changes made in Step 3 are shown in Visual Editor.

Additional context

This is due to the PostTextEditor component's "delayed sync" behavior, where we do not parse on individual keypresses, only when the user "finishes editing". The current metric for determining that a user has finished their edits is the blur event. But within this workflow, the blur event is not triggered (or at least not handled by PostTextEditor, perhaps due to the fact that it will have unmounted by the time it's called).

A possible fix may be to consider whether there are unsaved changes in the PostTextEditor's componentWillUnmount and invoking the onPersist prop.

[noisysocks]

A possible fix may be to consider whether there are unsaved changes in the PostTextEditor's componentWillUnmount and invoking the onPersist prop.

Looked into this. The problem is that componentWillUnmount is called in the same call stack as when SWITCH_MODE is dispatched which means that dispatching RESET_BLOCKS doesn't cause the UI to update.

We can fix this by calling onPersist in a setTimeout but that's a little too hacky for my liking.

I'm thinking that we should change our approach again so that onPersist is called on every key stroke. We can debounce it so that excessive undo levels aren't created.

Any thoughts?

[aduth]

The problem is that componentWillUnmount is called in the same call stack as when SWITCH_MODE is dispatched which means that dispatching RESET_BLOCKS doesn't cause the UI to update.

I'm curious to learn more about this. It doesn't seem to follow that the UI should ever be falling out of sync with state, regardless in which tick the change to state occurs.

What specifically do you observe? Are the blocks in the Visual Editor not "up to date" with changes made in the Code Editor?

[yankiara]

Hi all,

Any news about this???
Issue still here in WP 5.3 :-( How can this major bug still be present one year later?

How can we help? (coding, reviewing...?)

Thx,
Yan

[noisysocks]

Reported here also: https://core.trac.wordpress.org/ticket/47892

[noisysocks]

An issue related to this is that the Preview and Publish buttons don't transition from disabled to enabled until the text field is unfocused. See https://core.trac.wordpress.org/ticket/47791.

[jikamens]

I am genuinely surprised that this data loss bug (and yes, I have personally lost data because of this bug, so I'm not just talking about theoreticals here) has remained unfixed for more than two years.

[noisysocks]

Would you like to channel your frustration into a PR? It's very cathartic 🙂

[grzim]

Fixed in #9512

[mcsf]

Fixed in #9512

@grzim: see #29988 (comment)

[grzim]

The issue has to be reopened due to regression made by #9512

The issue can be solved in a different way than saving content on blur. The alternative is to save on switching editors.

[Mamaduka]

The issue was fixed in #40730 and will be included in WP 6.0.