Intermittently unable to start writing content when creating a new page in the Site Editor

[annezazu]

Description

Intermittently, when creating a new page from the Site Editor, I'm unable to start to add content and am not able to select the content block. This doesn't happen consistently but I can eventually replicate it consistently so I'm unsure what's breaking down.

I cannot replicate this in WP 7.0 beta 3 but I can in the latest of GB!

Step-by-step reproduction instructions

1. Go to Appearance > Editor
2. Add a page
3. Try to type content. If it works, keep going back to add a new page until you see you are unable to do so.

Screenshots, screen recording, code snippet

intermittently.unable.to.select.type.to.text.mov

Environment info

• WP 6.9.1
• GB Version 22.6.0
• Chrome

Please confirm that you have searched existing issues in the repo.

• Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

• Yes

Please confirm which theme type you used for testing.

• Block
• Classic
• Hybrid (e.g. classic with theme.json)
• Not sure

[annezazu]

I also can't replicate in Gutenberg nightly! Trying to track down what likely fixed this using AI and my own brain looking through recent PRs but can't quite find the cause. I'm going to leave this open to be extra safe to see if someone else might have more information to ensure this was properly fixed.

[tyxla]

I wonder if #76314 (which is part of the React 19 upgrade prep) resolved this.

Previously we had a hack where with a custom _load() call we manually signalled that the iframe document was ready, and this was potentially unreliable - if the timing was off (e.g., the iframe loaded before React attached the _load hack, or during the DOM manipulations), the iframe's contentDocument was not set, meaning the writing flow and typing observer refs could not be attached to the body. If my gut feeling is correct and this was the cause, as a result, users couldn't click into or type in the content area. And if that was the reason, then there's a chance #76314 fixed it.

cc @jsnajdr for thoughts and confirmation

[jsnajdr]

@tyxla Yes, it seems likely that the issue got accidentally fixed with #76314. It was merged in the last 24 hours, and the fact that the issue is no longer reproducible in nightly (trunk) supports this hypothesis.

If you can't type, a failure to mount the useWritingFlow or useTypingObserver hooks is a likely cause. And the loading changes in #76314 are very directly related to this. That PR generally tries to do the load "correctly" and to remove the complexity and the quirks that have accumulated there over time.

[tyxla]

@jsnajdr thanks for looking - can we confirm with certainty so we know if we can close this one?

[jsnajdr]

So far I haven't been able to reproduce this. Trying different environments, Playground... The best course of action will probably be wait for a few days, even weeks, and see if we see other cases.

[jsnajdr]

Ha! Just managed to reproduce it. There's one crucial step: you need to be in the template-locked rendering mode, i.e., have "Show Template" checked in the preview menu:

Let me now investigate what is going on.

[jsnajdr]

When this issue happens, the block elements are inert, and the content blocks are missing from the list view:

The correct scenario is that the blocks are clickable and the list view contains them:

@youknowriad @ellatrix Do you have any idea what might be going on here? Right after creating a page, in template-locked mode, how could the content blocks get into bad state? Inert + hidden from list view?

[youknowriad]

In "template locked" there's an extra component rendered in EditorProvider that is supposed to lock what's outside PostContent (update block editing mode if I recall properly), So my guess is that it could be related to that.

I've said it before but these non declarative editing mode actions were a mistake in the first place and can result in race conditions when used in multiple places. For instance one possibility here is that the new changes to "pattern insertion" (simple editing) could conflict with the "template-locked" behavior as probably both impact that "editing mode"... So the more we move into declarative configuration for blocks and avoid these actions the better to avoid this kind of issues.

[jsnajdr]

Another thing that happens intermittently is that the core/post-content block doesn't create the default paragraph block that should be the template content when there are no inner blocks. On the following screenshot, notice that the "Content" block doesn't have the expand arrow. The previous screenshots in comments above do have it.

This insertion should happen in useInnerBlockTemplateSync. That leads me to an idea that maybe this bug is related to @youknowriad's recent work on selection restoration. That touched the inner block sync code a lot.

[jsnajdr]

It's now almost certain that this is a regression caused by #75458. The optimization of resetting controlled blocks has an edge case that is buggy. I'll post a patch soon, once I understand Claude's very technical description of it 🙂