Critical editor failure after placing empty Classic editor in a container block

[QuietNoise]

Describe the bug
After placing an empty Classic block in a container (Column, Group) and leaving the edit page the said edit page is no longer accessible. Returning to the affected edit page results in a soft White Screen Of Death.
When accessing the crashed edit page the Developer Tools Console will show an error:
Uncaught (in promise) TypeError: Cannot read property 'name' of undefined
with callstack pointing to Gutenberg build.

To reproduce

1. Create or edit page.
2. Place a Column or Group block anywhere.
3. Inside the Column / Group place a Classic block.
4. Do not enter any content into the Classic block.
5. Save the post.
6. Refresh the edit page.
7. The result is a white screen and error reported in a Developer Tools console.

Expected behavior
I would expect the edit page to be accessible regardless whether the content in Classic editor is present or not.

Other notes
There is no apparent way to recover the page you are editing other than creating it from scratch.
The issue will appear also when you remove all content from existing Classic editor that sits in a container block.
This issue breaks edit ability of every existing page that already had empty Classic block in them (thus there is no way for user to avoid that failure if they already placed empty Classic in a container on the page in a past).
This seems to be related to other issue that was fixed with Gutenberg 6.3.0 (#13187).

Screenshots
Error as reported by local WP installation.

Error as reported by wordpress.com.

Desktop (please complete the following information):

• OS: Windows
• Browser: Chrome 76, Firefox 68

Additional context

• WP 5.2.2
• Gutenberg 6.3.0
  Issue also appears on wordpress.com.

[donmhico]

Hello @QuietNoise. Thank you for your report. I can confirm the bug.

WP Version: 5.3-alpha-45282-src
Gutenberg: Latest commit 6ecff18.

I'll try to see if I can request a PR fix later.

[donmhico]

Notes:

If an empty "Classic Editor" is saved in the "root" (not inside a column), it won't be saved. The post->post_content is empty. While if it's saved inside a column, the post->post_content saved is

<!-- wp:columns -->
<div class="wp-block-columns"><!-- wp:column {"width":33.33} -->
<div class="wp-block-column" style="flex-basis:33.33%"><!-- wp:freeform /--></div>
<!-- /wp:column -->

<!-- wp:column {"width":66.66} -->
<div class="wp-block-column" style="flex-basis:66.66%"></div>
<!-- /wp:column --></div>
<!-- /wp:columns -->

I supposed we can either just make it so that <!-- wp:freeform /--> won't be saved if it's empty. Or be able to properly handle<!-- wp:freeform /-->. I'm much more inclined with the later.

I'm quite new to Gutenberg so it would take me more time before I can produce a fix.

[talldan]

@donmhico There used to be this bug with using the classic block as a nested block #13187, this was the fix: #16477.

[mcsf]

This issue was closed by #17164 in the sense that the PR prevents the editor from crashing when handling nested empty freeform blocks.

However, with that fix the editor will disregard any empty freeform block present in a nested context. Adding support for this could be achieved by tweaking the serialiser per #17164 (comment), if this is still deemed a pertinent fix.

I don't feel strongly about supporting persistent empty freeform blocks, but any interested parties should open an issue if they feel otherwise.

[QuietNoise]

Cool. Glad that the fix for the breaking part went through.

@mcsf I have some use cases for keeping empty Classic editor as is which you might consider:

1. Placing placeholders for content that will be placed later. Any scenario where you prepare more complex layouts might be valid case. I.e. where you prep a layout with empty Classics, preview it and come back to add more content later. Re adding Classic seems counter productive.
2. Reusable blocks with empty Classic block in them and / or empty page templates with empty classic blocks ready to be cloned for new content.

While the first use case is something most people can live without then in second case removing something that a developer or content supervisor deliberately placed in seems against smooth UX experience.

Also 2nd use case will prevent non savvy users from properly filling the content as they will not know where and if there was a Classic editor meant to be in a given container.

Second, I reckon the behaviour will be inconsistent / confusing in a way that empty Classic blocks placed as roots won't disappear while empty Classic blocks from Column / Groups will.
I wonder should I open a new issue or would you rather pick up from here.

[mcsf]

Thanks for the detailed reply, @QuietNoise.

1. Placing placeholders for content that will be placed later. Any scenario where you prepare more complex layouts might be valid case. I.e. where you prep a layout with empty Classics, preview it and come back to add more content later. Re adding Classic seems counter productive.

If you don't mind my asking, how often do you do this with Classic blocks? While there's nothing wrong with using Classic blocks in nested contexts, it's surprising to me, since they were mainly conceived as a way of providing a smooth path from old editor to new editor with blocks doing the work for you.

Secondary question, also out of curiosity: have you ever overridden the editor's configuration to use some other block type that isn't Classic as Freeform?

While the first use case is something most people can live without then in second case removing something that a developer or content supervisor deliberately placed in seems against smooth UX experience.

Also 2nd use case will prevent non savvy users from properly filling the content as they will not know where and if there was a Classic editor meant to be in a given container.

Second, I reckon the behaviour will be inconsistent / confusing in a way that empty Classic blocks placed as roots won't disappear while empty Classic blocks from Column / Groups will.

I agree with all these arguments in principle.

I wonder should I open a new issue or would you rather pick up from here.

If you don't mind, I'd love it if you could open the issue. Feel free to copy-paste some of what's been discussed here, and point to this issue and mention me if you like. Thanks!