Gutenberg: FSE: Adding a post content block to a post causes a WSOD

[carolinan]

Describe the bug
With full site editing enabled, it is possible to add a post content block to a post.
This causes a WSOD on the front.

In the console of the editor I see the following error:

react-dom.js?ver=16.9.0:539 Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application. To fix, cancel all subscriptions and asynchronous tasks in the componentWillUnmount method.
    in r (created by Context.Consumer)
    in v (created by C)
    in C (created by BlockSettingsMenuControlsSlot)
    in BlockSettingsMenuControlsSlot
    in Unknown (created by r)
    in div (created by r)
    in r (created by ForwardRef(NavigableContainer))
    in ForwardRef(NavigableContainer) (created by ForwardRef)
    in ForwardRef (created by r)
    in div
    in div (created by ForwardRef)
    in ForwardRef
    in Unknown (created by W)
    in r (created by WithFocusOutside(r))
    in div (created by WithFocusOutside(r))
    in WithFocusOutside(r) (created by W)
    in Unknown (created by f)
    in div (created by f)
    in f (created by Context.Consumer)
    in WithFocusReturn(Component) (created by WithConstrainedTabbing(WithFocusReturn(Component)))
    in div (created by WithConstrainedTabbing(WithFocusReturn(Component)))
    in WithConstrainedTabbing(WithFocusReturn(Component)) (created by W)
    in S (created by M)
    in M (created by W)
    in span (created by W)
    in W (created by r)
    in div (created by r)
    in r (created by Kr)
    in Kr
    in div (created by Va)
    in Va (created by Ba)
    in Ba (created by ps)
    in ps
    in Unknown (created by WithDispatch(Component))
    in WithDispatch(Component)
    in Unknown (created by WithSelect(WithDispatch(Component)))
    in WithSelect(WithDispatch(Component)) (created by Su)
    in Su (created by Mu)
    in div (created by Mu)
    in Mu (created by uc)
    in div (created by r)
    in r (created by ForwardRef(NavigableContainer))
    in ForwardRef(NavigableContainer) (created by ForwardRef)
    in ForwardRef (created by sc)
    in sc (created by uc)
    in div (created by uc)
    in uc (created by fc)
    in div
    in div (created by ForwardRef)
    in ForwardRef
    in Unknown (created by W)
    in r (created by WithFocusOutside(r))
    in div (created by WithFocusOutside(r))
    in WithFocusOutside(r) (created by W)
    in S (created by M)
    in M (created by W)
    in W (created by fc)
    in fc (created by pc)
warningWithoutStack @ react-dom.js?ver=16.9.0:539
warnAboutUpdateOnUnmountedFiberInDEV @ react-dom.js?ver=16.9.0:23315
scheduleUpdateOnFiber @ react-dom.js?ver=16.9.0:21532
enqueueForceUpdate @ react-dom.js?ver=16.9.0:13283
Component.forceUpdate @ react.js?ver=16.9.0:431
(anonymous) @ index.js?ver=e11eeaeb4a7db2fe31218b09cb0efae2:6
commitHookEffectList @ react-dom.js?ver=16.9.0:20124
commitLifeCycles @ react-dom.js?ver=16.9.0:20169
commitLayoutEffects @ react-dom.js?ver=16.9.0:22951
callCallback @ react-dom.js?ver=16.9.0:341
invokeGuardedCallbackDev @ react-dom.js?ver=16.9.0:391
invokeGuardedCallback @ react-dom.js?ver=16.9.0:448
commitRootImpl @ react-dom.js?ver=16.9.0:22723
unstable_runWithPriority @ react.js?ver=16.9.0:2820
runWithPriority$2 @ react-dom.js?ver=16.9.0:11443
commitRoot @ react-dom.js?ver=16.9.0:22552
runRootCallback @ react-dom.js?ver=16.9.0:21692
(anonymous) @ react-dom.js?ver=16.9.0:11491
unstable_runWithPriority @ react.js?ver=16.9.0:2820
runWithPriority$2 @ react-dom.js?ver=16.9.0:11443
flushSyncCallbackQueueImpl @ react-dom.js?ver=16.9.0:11487
flushSyncCallbackQueue @ react-dom.js?ver=16.9.0:11476
discreteUpdates$1 @ react-dom.js?ver=16.9.0:21815
discreteUpdates @ react-dom.js?ver=16.9.0:2357
dispatchDiscreteEvent @ react-dom.js?ver=16.9.0:6104

Chrome:
In the console of the front I see the following error:
Failed to load resource: net::ERR_INCOMPLETE_CHUNKED_ENCODING

Firefox:
Refuses to load the post at all.

To reproduce
Steps to reproduce the behavior:
1.Enable full site editing

1. Create a new post in the regular block editor
2. Add a post content block and save
3. View the post on the front

Expected behavior
Posts should not be able to include _themselves_, I would assume it causes a infinite loop.

I am not sure what the solution would be:
Either disable the block in the post editor,
Or displaying a placeholder explaining that en error occurred (only visible to user with the correct privileges).

Editor version (please complete the following information):

• WordPress version: 5.4.1
• Gutenberg 8.0.0

Desktop (please complete the following information):

• Windows 10
• Chrome version: 81.0.4044.129
  
  
  
  • Firefox version 75.0
  
  

[iandunn]

I ran into this under different conditions, but also with the v8.0.0 tag.

Once I switched to master, though, it went away. @carolinan, do you still get the error on master?

Related: #19642, #17355

---

For reference:

Preconditions

• Latest Core (3d31284c5e), plugin v8.0.0 tag.
• Firefox
• React Dev Tools extension activated
• All plugin experiments _disabled_, including FSE
• SCRIPT_DEBUG enabled

Steps to reproduce

1. Start new page, the cursor is automatically at the title
2. Hit down to enter the empty paragraph block
3. Type hello and hit enter
4. Press control-z to undo. The error appears in the console.

[carolinan]

For the last two days I have tried to test with the master but the recent changes to templates broke something with FSE so no templates are found.

With Gutenberg version 8.1.0 I am a not seeing a WSOD but the following:

On the front, viewing my _single_ template created in the site editor:
Fatal error: Allowed memory size of 134217728 bytes exhausted (tried to allocate 20480 bytes) in /var/www/html/wp-includes/class-wp-user.php on line 515

In the standard block editor, _trying to view an already saved post with a post content block:_

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in /var/www/html/wp-includes/class-wp-object-cache.php on line 290 Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 262144 bytes) in Unknown on line 0

In the Site editor, the single template shows the placeholder for the content correctly.

[johnstonphilip]

I am seeing the same thing here as @carolinan today on master latest.

Just noting one difference in my case: I am adding it to a wp template part, not a post.

[kjellr]

I'm seeing this block crash in 8.4 too — originally opened #23429 to report it before seeing this issue.

It currently appears to break before I can add the block to the page.

To reproduce:

1. Activate the Full Site Editing experiment.
2. Create a new page
3. Try to add the "Post Content" block to your page.
4. Note that the page freezes/errors.

For me it's just freezing the whole page after that, but @jffng tried it and it gave him this error:

[youknowriad]

We shouldn't allow adding "post content" inside "post content", that's obviously an infinite loop. We'd need to find a way to exclude this block from the regular post/page editor.

[carolinan]

Or show it as a placeholder?

[youknowriad]

A placeholder means there's content that will be added there later and in this case, we can't add anything there, so I'd prefer to just disable the block but not sure exactly how

[carolinan]

The reason why one wants to add a content block in the editor is because is tedious to test block layouts using the HTML files.

We need something to represent the content, to build a full page layout around it. So for me it's not as much adding something later, as it is _show me that something will be displayed on the front._

Because the site editor has been in various states of broken, this early on, it has not been the first place to go to when testing templates, the standard block editor has. Once the site editor is more stable, this pattern for testing and generating block grammar will perhaps change.

[youknowriad]

I understand and that makes sense but I believe it's better for us to focus on fixing the site editor issues instead of introducing this temporary measure? How far are we from being able to start building templates directly in the Site Builder?

[epiqueras]

Is this still happening on master? There's been a lot of related changes recently. @ockham @Addison-Stavlo @noahtallen

[Addison-Stavlo]

Is this still happening on master?

@epiqueras - I just tested it on my local environment and that seems to be the case. It crashes when added in the post editor ( for posts, pages, Templates, etc.).

[ockham]

I agree with @youknowriad that we should remove the Post Content block from the Post Editor _when editing post content_, but it should be okay to add it when editing a Template or Template Part (in the Post Editor) I guess? Though a point can be made that that's also not a totally well-defined scenario.

@carolinan Have you tried the Site Editor for editing templates lately? Would be curious if it's working better for you now, or if there are some remaining big blockers?

[epiqueras]

We need to hardcode a set of post types for which the post content block should always only show a placeholder to avoid infinite looping in the editor.

[aristath]

This still happens when creating an FSE template btw, it's not limited to posts/pages. I'd expect it to work in the context of a template... :thinking:

[noahtallen]

we need to circle back to this PR: #24010, which shows a "placeholder" instead of crashing the editor in that scenario :)

[noahtallen]

This should be fixed now!

[aristath]

confirmed fix :+1: