Integrate Resizable Editor with Device Preview#75121
Open
Conversation
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?
Member
There was a problem hiding this comment.
I think there's an opportunity to combine the constants and logic with the (already merged) block visibility code,
Part of the roadmap there is to add configurable breakpoints in theme.json and eventually in the UI
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
|
Contributor
|
Oh whoops, I didn't realise linking to a comment from my other PR would close this one! Sorry 😅 |
ramonjd
reviewed
Feb 8, 2026
| * @param {number} canvasWidth The canvas width in pixels. | ||
| * @return {string} The device type. | ||
| */ | ||
| export function getDeviceTypeByCanvasWidth( canvasWidth ) { |
Member
There was a problem hiding this comment.
I'd be interested in how we can share this code with the block visibility hook
Or would these changes make most of the device type/current viewport width logic in useBlockVisibility redundant?
ramonjd
reviewed
Feb 8, 2026
| <MenuGroup> | ||
| <MenuItemsChoice | ||
| choices={ choices } | ||
| value={ deviceType } |
Member
There was a problem hiding this comment.
After I resize the canvas, then open the dropdown, matchedDeviceType is undefined.
Kapture.2026-02-09.at.09.25.39.mp4
I guess because getMatchedDeviceTypeByCanvasWidth only returns a value when the canvas width exactly matches one of the preset device widths.
For the block visibility work, the useBlockVisibility hook dealt in ranges:
What do you think?
Contributor
|
Absent any other design feedback about the theoretical responsive edit consequences I outlined, feel free to land this. I still think there's something to untangle there, but given the main responsive feature in 7 will be block hiding, and that these resize handles are very useful (#62748), we shouldn't block it from happening. The main question to answer is: for responsive editing, will we eventually embrace that all edits made on lower-than-desktop breakpoints apply responsively? |
Member
Just to make sure I understand, do you mean whether any edits made between breakpoint Or rather, do you see this mode of previewing as something to be "turned on or off"? I think it raises similar questions we asked around block visibility, namely around discoverability and how we can help users track all the block states they've set. It sounds very reasonable to me that we'd want to apply the edits at their corresponding breakpoints in the editor. It'll be an interesting challenge to communicate to the user what's going on on the editor canvas. Anyway, lots to discuss around that later! 🙇🏻 |
Contributor
Yes. That's the perspective that I have in mind, and related to what I perceived to be the ultimate purpose of Matías now-closed PR: we need to allow any property to be editable on the various breakpoints. Let me break it down (pun intended):
Use case: small font size on mobile, large font size on desktop. Or hidden block on mobile, visible on tablet and above. We're taking step by step to get to the destination here; I understand editing of exisitng breakpoint values is on the way, and block hiding is obviously here. It's certainly looking like 7.1 at this point, but the open questions for me are around the UI:
As an example, I believe other players in the space do desktop first, and that simply choosing a breakpoint means customizing values from that breakpoint and downwards. I.e. I'd choose "Tablet", edit a font size to be smaller, and now that font size is smaller for tablet and mobile. The key here is, that recasts the responsive dropdown to be about responsive edits, not about previewing it. I find this the simplest because the editor itself is already a preview, and if we were able to say: you can just pull the vertical separator between canvas and inspector to resize it, al la this, then you could still have an easily resizable preview without having to use the responsive dropdown. If we did go that route, this PR could still land, but in the future I describe each action you change while having resized the viewport with this interface, would be a responsive edit. Which is where I worry there might be confusion. The alternative would be going back to something like what Matías had in the PR: a toggle: "now I'm making responsive edits", that you had to toggle first. CC: @youknowriad |
Contributor
|
I take it there’s no concern that this does away with the height – and therefore aspect ratio – of the tablet and mobile previews? I don’t think it’s a problem. It has a bit of an upside that it eliminates the nested scrolling area for screens that don’t fit the full height. Tangentially, maybe in some future version of things, zoom out could integrate with device previews to “auto-fit” previews with any aspect ratio or even desktop previews from smaller screens. |
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
7 participants
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