Refactor block editor components to remove zoom out mode dependencies #71807
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ramonjd
commented
Sep 22, 2025
| isUsingBindings: _isUsingBindings, | ||
| hasParentPattern: _hasParentPattern, | ||
| hasContentOnlyLocking: _hasTemplateLock, | ||
| // @ZOOMOUTMODE |
Member
Author
There was a problem hiding this comment.
This comment is to indicate questionable areas... that is, "should I stay or should I go". Like that song.
Contributor
There was a problem hiding this comment.
For the showShuffleButton I'm not sure how useful it is in its current form as it shows a very simple set of patterns in the same category. It feels like something that looks good in theory but I struggle to imagine how it would feel in actual usage, as you'd need a really good set of comparable patterns for it to work well:
|
Size Change: -1.27 kB (-0.06%) Total Size: 2.27 MB
ℹ️ View Unchanged
|
andrewserong
added
[Feature] Zoom Out
[Type] Enhancement
andrewserong
force-pushed
the
try/decouple-zoom-mode-from-editor
branch
2 times, most recently
from
92c238c to
05db748
Compare
andrewserong
reviewed
Oct 7, 2025
andrewserong
reviewed
Oct 7, 2025
Comment on lines
504
to
506
| // @ZOOMOUTMODE | ||
| enablePaddingAppender: | ||
| ! isZoomOut() && isRenderingPostOnly && isNotDesignPostType, | ||
| isRenderingPostOnly && isNotDesignPostType, |
Contributor
There was a problem hiding this comment.
This removal is good, because we never allow the zoom out button when isRenderingPostOnly as there isn't a section root id in that context (when we're in post-only mode).
Contributor
Thanks! I've made a start and will remove I'll continue on with this tomorrow and through the week 👍 |
Member
Author
|
Thanks for going deeper on this one @andrewserong ! |
andrewserong
force-pushed
the
try/decouple-zoom-mode-from-editor
branch
from
4f05718 to
275e4ab
Compare
andrewserong
reviewed
Oct 8, 2025
Comment on lines
37
to
+38
| // Check if the block is still selected at the time this effect runs. | ||
| if ( | ||
| ! isBlockSelected( clientId ) || | ||
| isMultiSelecting() || | ||
| isZoomOut() | ||
| ) { | ||
| if ( ! isBlockSelected( clientId ) || isMultiSelecting() ) { |
Contributor
There was a problem hiding this comment.
I've removed isZoomOut from this check, otherwise we get stuck on a row if we hit "enter" while zoomed out:
Before
2025-10-08.16.55.03.mp4
With this removal
2025-10-08.16.54.18.mp4
Member
Author
|
What's your take on editing pattern content blocks while zoomed out? Here's I switched on the content only experiment: Kapture.2025-10-08.at.17.31.38.mp4They're not editable while zoomed out. I'm not sure if that's expected or not. It does make it easier to grab and drag the pattern elsewhere though 🤔 |
ramonjd
force-pushed
the
try/decouple-zoom-mode-from-editor
branch
from
275e4ab to
2414d13
Compare
Member
Author
|
I just rebased to fix a conflict 👍🏻 |
Member
Author
The unit test fail is real. Sorry if I caused it! at Object.toEqual (packages/block-editor/src/store/test/reducer.js:4468:40) |
Contributor
No, no, they were already failing, I hadn't gotten to looking at them yet as I was still umming and ahing over the ideal behaviour here.
For the purposes of this PR, I think you probably should be able to. Whether or not this PR as a whole winds up feeling right is another question, though. But from the premise of "let's decouple zoom out from editing behaviour" I like the idea of seeing how it feels to enable that kind of editing and updating while zoomed out, though I don't feel strongly about it! |
andrewserong
force-pushed
the
try/decouple-zoom-mode-from-editor
branch
from
2414d13 to
f8c1d4d
Compare
Contributor
I think we can have the best of both worlds of the pattern being draggable and the blocks within it being editable. It took me way longer to find a fix than I'd expected, but it turns out that by recalculating the derived block editor modes when zoom out mode is changed, that got it working again (I suspect because we were stuck with a cached value where the parent block is disabled and so the child blocks think they are, too? Not too sure). In any case, with this tiny commit (f8c1d4d) that adds a couple of actions back in to recalculate that state, that's gotten it working, with pattern fields editable while zoomed out: 
That's about all the time I have for this PR before I go AFK for a week, but happy to pick it up again when I'm back if it's still open! |
1 task
ramonjd
force-pushed
the
try/decouple-zoom-mode-from-editor
branch
from
f8c1d4d to
6d40791
Compare
andrewserong
force-pushed
the
try/decouple-zoom-mode-from-editor
branch
from
9fc90c9 to
a602c32
Compare
Contributor
|
A few things I noticed:
Just some thoughts, nothing to block this work. |
- Simplified state management in block-list and related components by removing isZoomOut checks. - Updated logic in block settings dropdown and block tools to enhance performance and maintainability. - Cleaned up unused imports and adjusted related functionality to ensure consistent behavior without zoom out mode.
…ayActive block overlay logic in selectors.js
andrewserong
force-pushed
the
try/decouple-zoom-mode-from-editor
branch
from
a602c32 to
01b78d3
Compare
Contributor
Good question. I think part of the challenge here is that if we're enabling the inbetween inserter, then the two will conflict: 
I like that idea. I think I'd probably treat it as a separate step. I.e. first see if we can land this PR to make Zoom Out less opinionated, and then once we're happy with how it's functioning, open up a smaller PR to make Zoom Out more readily available. |
Contributor
|
Just jotting down a couple of visual bugs: Positioning of the block inserter: 
Highlighting of the block drop zone (the width is correct when zoomed in, but not while zoomed out): 
|
Contributor
I've partially fixed these in ad4be2c which allows the BlockPopoverCover to account for scaling by using 
|
Comment on lines
+4022
to
+4024
| it( 'returns empty block editing modes since zoom does not affect editing modes', () => { | ||
| // Zoom level is decoupled from editing modes, so even when | ||
| // zoomed out with sections, no derived editing modes should be set. |
Contributor
There was a problem hiding this comment.
For now, I've updated some of these tests to expect an empty Map(). If/when this PR is ready to land, I think we'll just rip out the zoomOut tests altogether rather than testing it doesn't do anything. But for now I'm finding it helpful to keep them in, just to keep track.
Member
Author
There was a problem hiding this comment.
But for now I'm finding it helpful to keep them in, just to keep track.
Good thinking!
Member
Author
Yeah, as I was testing this again I created a new template and was trying to remember why zoom wasn't enabled when adding patterns. To me, making its appearance consistent sounds worth it in whatever follow ups we do.
Butter 🧈 Kapture.2025-10-24.at.14.01.28.mp4 |
| // Other operations such as "group" are when the editor tries to create a row | ||
| // block by grouping the block being dragged with the block it's being dropped | ||
| // onto. | ||
| // @ZOOMOUTMODE |
Contributor
There was a problem hiding this comment.
Grouping while dragging onto things horizontally can be a fairly fine-grained action. For now, I lean toward leaving this in (return early if we're not inserting), but we could always revisit in follow-ups. I'll remove this comment for now.
…p while zoomed out
Comment on lines
128
to
130
| // The switch style button appears more prominently with the | ||
| // content only pattern experiment. | ||
| // @ZOOMOUTMODE |
Contributor
There was a problem hiding this comment.
I'm inclined to keep this one, as I think quickly being able to toggle through the section styles is nice behaviour 👍
|
Flaky tests detected in 20aaf5e. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/18768564501
|
Contributor
|
Closing for now, let's revisit once the contentOnly experiment has been stabilised (i.e. once contentOnly is in a good place, and features for it are decoupled from Zoom Out mode, we'll be in a better place to pick this work up again to tidy up Zoom Out). Slightly longer explanation in the linked issue here: #71556 (comment) Thanks for all the discussion and back-and-forth, folks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Kapture.2025-10-14.at.13.32.16.mp4
(Hopefully one day) resolves #71556
This PR attempts to remove all editing-related constraints from zoom out mode. The goal is for zoom out to feel more like you're simply zooming out, rather than fundamentally changing how you interact with blocks.
So, when you zoom out you should still be able to select and edit editable fields.
To achieve these changes, this PR also updates the
BlockPopoverCoverto calculate the size of the area usinggetBoundingClientRectinstead of offset width/height, so that it factors in scaling.Testing Instructions