Block Editor: Prevent Enter key from inserting paragraphs in contentOnly sections#76989
Block Editor: Prevent Enter key from inserting paragraphs in contentOnly sections#76989
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +7 B (0%) Total Size: 7.74 MB 📦 View Changed
ℹ️ View Unchanged
|
|
Flaky tests detected in 24b9b8c. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24062843428
|
013b1ba to
c4c5d5c
Compare
3c41ed9 to
98a026d
Compare
t-hamano
left a comment
There was a problem hiding this comment.
Thanks for the PR, this PR works well, and the changes make sense to me.
Can we update the following comments according to the updated if condition? I believe we need to explicitly state the reason for checking both contentOnly and disabled.
gutenberg/packages/block-editor/src/store/selectors.js
Lines 1750 to 1754 in 98a026d
gutenberg/packages/block-editor/src/store/selectors.js
Lines 1767 to 1768 in 98a026d
98a026d to
6a972b3
Compare
Done! Thank you @t-hamano! |
…nly sections When a block like Cover sits inside a nested container (e.g. Column) within a contentOnly pattern, pressing Enter inserts a paragraph that can't be removed. canInsertBlockType didn't consider containers with 'disabled' editing mode when applying content-only insertion rules, so the disabled Column fell through and the paragraph was allowed. Include 'disabled' in the content-only check in canInsertBlockType so these containers go through the same sibling paragraph logic.
…n content-only sections.
6a972b3 to
24b9b8c
Compare
…nly sections (#76989) Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: talldan <talldanwp@git.wordpress.org> Co-authored-by: t-hamano <wildworks@git.wordpress.org>
|
I just cherry-picked this PR to the wp/7.0 branch to get it included in the next release: 81c2796 |
…nly sections (#76989) Co-authored-by: ramonjd <ramonopoly@git.wordpress.org> Co-authored-by: talldan <talldanwp@git.wordpress.org> Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Fixes a bug where pressing Enter on a non-text block (e.g. a Cover block) inside a contentOnly pattern inserts an empty paragraph that can't be removed.
See #73222 (comment)
Why?
When a block like Cover sits inside a nested container (Column) within a contentOnly pattern, pressing Enter inserts a paragraph via
insertAfterBlock. The paragraph gets created becausecanInsertBlockTypedidn't consider containers withdisabledediting mode when applying content-only insertion rules.The condition only matched
contentOnlyand section block parents, so thedisabledColumn fell through and the paragraph was allowed. ButcanRemoveBlockrespects the Column'sdisabledediting mode, so the paragraph gets stuck.How?
Include
blockEditingMode === 'disabled'in the content-only insertion check incanInsertBlockTypeso that disabled containers (like Column inside a contentOnly section) go through the same "has existing sibling paragraph" logic.Testing Instructions
Also verify normal editing still works:
Screenshots
How it worked before
572275680-578c1a42-b86e-4eef-83ca-8a6436d335b1.mp4
How it should work (this PR)
2026-04-02.15.08.15.mp4