Integrate Resizable Editor with Device Preview #75121
Open
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
github-actions
bot
added
[Package] Editor
|
Size Change: +311 B (+0.01%) Total Size: 3 MB
ℹ️ View Unchanged
|
t-hamano
commented
Feb 2, 2026
| <PreviewDropdown | ||
| forceIsAutosaveable={ forceIsDirty } | ||
| disabled={ disablePreviewOption } | ||
| disabled={ isStylesCanvasActive } |
Contributor
Author
There was a problem hiding this comment.
The only exception is StyleBook, where the device preview dropdown is not available, and the canvas is not resizable. I plan to remove this limitation in a follow-up.
t-hamano
requested review from
Mamaduka,
ellatrix,
jameskoster,
jasmussen,
ramonjd,
stokesman,
tellthemachines and
youknowriad
t-hamano
added
[Type] Enhancement
|
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. |
Mamaduka
reviewed
Feb 2, 2026
Member
Mamaduka
left a comment
Mamaduka
left a comment
There was a problem hiding this comment.
I haven't tested this thoroughly, but I've left some notes based on the initial review.
I think it's an interesting approach. Can you elaborate a bit on why a new global state is needed rather than just using the previous method?
Contributor
Author
|
@Mamaduka Thanks for the review!
The reason I introduced the new |
Member
|
Yes, but what prevents us from using I'm not saying that either option is better; I'm primarily curious about the technical decisions. |
Contributor
Can you give me some steps to repro this? A quick check of the pattern editor by creating a new pattern, adding a block and selecting "hide on desktop" hides it successfully for me: 
We're not only checking the device type but also the viewport size for the block hiding logic, so if it doesn't work in responsive editing there's something wrong with it 😅 |
Contributor
Author
@tellthemachines Can you try the following steps? I tested it on trunk (f2c4004).
d0d26373639acd414cd859e8ce4e469a.mp4 |
Contributor
Author
@Mamaduka Can you elaborate a bit more on your concerns? I may not be understanding you properly 😅 |
Contributor
|
Nice, this looks great. There are some considerations, though, to be mindful of. Firstly, #73888 (which to my surprise is closed at the moment), but it nevertheless details using the viewport dropdown as a means to do responsive edits. One of the design conversations was whehter there should be a toggle inside, or not, and so far the latest instincts have gone towards this: 
That is, since the dropdown is already so tailored to breakpoints, might as well not include the toggle at all, that any choice other than desktop, engages the responsive editing mode. Combine that with the ability to edit the values of each of the two breakpoints, and you have a viewport dropdown that is a bit more flexible than we're used to. That doesn't necessarily mean you can't do what you are proposing here—all that might still be valid. But the thing about those resize handles is that they are so useful in isolated editing mode for just previewing, that it might bring new appeal to using the viewport dropdown, and if that gets locked to making responsive edits, it's going to become a source of confusion. Mainly, I'd love @WordPress/gutenberg-design input here, and on the following thought, which is we should do one of the following:
I don't particularly love either of the above. But one of the main sources for this, is that the viewport dropdown is not a very discoverable place for hosting the "Preview in new tab" button. In using a Desktop icon, it suggests responsive tools, not previewing. The answer could be to move the option to a new page dropdown from the center title: 
That's being discussed here, but it's going a bit back and forth. |
Contributor
|
I like the direction of this PR. I think this is going to make it easier to implement custom breakpoints which is definitely something that folks are going to require for responsive editing. |
youknowriad
reviewed
Feb 2, 2026
| } | ||
|
|
||
| const deviceTypeByCanvasWidth = getDeviceTypeByCanvasWidth( canvasWidth ); | ||
| const matchedDeviceType = getMatchedDeviceTypeByCanvasWidth( canvasWidth ); |
Contributor
There was a problem hiding this comment.
Why do we need two kind of matching?
youknowriad
reviewed
Feb 2, 2026
| icon: mobile, | ||
| canvasWidth: 480 - 1, // preview for useViewportMatch( 'mobile', '<' ) | ||
| }, | ||
| }; |
Contributor
There was a problem hiding this comment.
So what's the plan there? Move this to the core "theme.json" in a follow-up?
Contributor
Thanks Aki, I can reproduce it now! The problem is that useViewportMatch doesn't know about the editor iframe size. I'll put up a fix for that shortly. That fix shouldn't invalidate this PR, because it only fixes the block hiding bug. I'd still love to see the resizable editor used everywhere! Though @jasmussen raises some good points; this needs a bit more thought to reach the optimal solution. Edit: fix in #75156 |
Member
|
I think this was closed by accident. |
|
Flaky tests detected in 07c3984. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/21616457870
|
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.
What? Why?
Currently, we believe that device view and resizable editor are mutually exclusive, causing two major problems. This PR attempts to solve these problems by unifying the two modes:
Device View
In editors where device view is available, you cannot set any width other than the three device types. This includes the post editor, template editor, etc.
Resizable Editor
In resizable editors,
getDeviceTypealways returns Desktop, so the block hiding feature does not work in resizable editors, such as the Pattern Editor and Navigation Editor.How?
Here's a summary of the approach:
getDeviceTypeandsetDeviceTypeessentially act as wrappers for referencing and updating this newcanvasWidth:getDeviceTypewill return the appropriate device type based on the current canvas width: 481px wide or less is considered'Mobile', 781px or less is considered'Tablet', and anything else is considered'Desktop'.setDeviceTypeinternally sets the canvas width corresponding to the device type:undefinedfor Desktop,781pxfor Tablet, and479pxfor Mobile.useResizeCanvashook and make it a no-op function. Because this hook was for the device view.Testing Instructions
Post Editor, Template Editor
4dd92e2f8dde1b20e416c7c63516bf3e.mp4
Pattern Editor
The resize handles are always visible in this editor. Make sure the device preview dropdown and canvas width work together nicely.
7f71a97bacedc7e0526cc396311b7b28.mp4
Block Visibility
Related to #73735
8f8f000ca6dc4ac76a424659bbd823c4.mp4
With MetaBox
They should work well together without conflict.
4cec1f6a9b2d1b6dcb2976aad7b015f9.mp4