Block visibility: add viewport modal and controls UI #74249
Merged
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
|
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: +3.26 kB (+0.11%) Total Size: 3.05 MB
ℹ️ View Unchanged
|
ramonjd
force-pushed
the
add/viewport-block-visibility-modal
branch
from
102eb49 to
01e5685
Compare
ramonjd
added
[Type] Enhancement
ramonjd
requested review from
aaronrobertshaw,
andrewserong,
Copilot,
talldan and
tellthemachines
There was a problem hiding this comment.
Pull request overview
This PR adds viewport-based block visibility controls (mobile, tablet, desktop) behind the window.__experimentalHideBlocksBasedOnScreenSize experimental flag. The implementation includes a modal UI for configuring visibility across different viewport sizes while maintaining backward compatibility with the existing simple toggle behavior.
Key Changes:
- Adds a modal-based UI for configuring block visibility across mobile, tablet, and desktop viewports with multi-block editing support
- Implements store-based modal state management with new reducer, actions, and selectors
- Provides multiple entry points for the visibility modal (toolbar, menu, command palette, keyboard shortcuts, list view, and canvas context menus)
Reviewed changes
Copilot reviewed 19 out of 19 changed files in this pull request and generated 6 comments.
Show a summary per file
| File | Description |
|---|---|
| packages/editor/src/components/provider/index.js | Integrates BlockVisibilityModalManager into the editor provider |
| packages/block-editor/src/store/reducer.js | Adds blockVisibilityModal reducer to track modal open/closed state |
| packages/block-editor/src/store/private-selectors.js | Adds getBlockVisibilityModalState selector for retrieving modal state |
| packages/block-editor/src/store/private-actions.js | Adds openBlockVisibilityModal and closeBlockVisibilityModal actions |
| packages/block-editor/src/private-apis.js | Exports BlockVisibilityModalManager as private API |
| packages/block-editor/src/components/use-block-commands/index.js | Adds command palette support with conditional behavior based on experimental flag |
| packages/block-editor/src/components/list-view/block.js | Integrates modal trigger in list view keyboard shortcuts and context menu |
| packages/block-editor/src/components/list-view/block-select-button.js | Updates list view icon display to use new visibility hook |
| packages/block-editor/src/components/block-visibility/viewport-toolbar.js | Implements new toolbar button for viewport-based visibility |
| packages/block-editor/src/components/block-visibility/viewport-menu-item.js | Implements new menu item for viewport-based visibility |
| packages/block-editor/src/components/block-visibility/utils.js | Adds utility functions for checking block visibility across viewports |
| packages/block-editor/src/components/block-visibility/useBlockVisibility.js | Provides custom hook for visibility state management |
| packages/block-editor/src/components/block-visibility/style.scss | Adds styling for the visibility modal UI |
| packages/block-editor/src/components/block-visibility/modal.js | Implements the main modal component with viewport checkboxes and form handling |
| packages/block-editor/src/components/block-visibility/modal-manager.js | Manages modal rendering based on store state |
| packages/block-editor/src/components/block-visibility/index.js | Conditionally exports viewport or default components based on experimental flag |
| packages/block-editor/src/components/block-visibility/constants.js | Defines viewport types (mobile, tablet, desktop) with labels and icons |
| packages/block-editor/src/components/block-tools/index.js | Adds keyboard shortcut handler with conditional modal opening |
| packages/block-editor/src/components/block-settings-menu-controls/index.js | Updates block settings menu to use new visibility hook |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
packages/block-editor/src/components/block-visibility/viewport-toolbar.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/block-visibility/useBlockVisibility.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/block-visibility/style.scss
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/use-block-commands/index.js
Outdated
Show resolved
Hide resolved
packages/block-editor/src/components/use-block-commands/index.js
Outdated
Show resolved
Hide resolved
ramonjd
commented
Jan 2, 2026
ramonjd
force-pushed
the
add/viewport-block-visibility-modal
branch
from
131b2bf to
4b6cbce
Compare
|
Flaky tests detected in a7a69a3. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20652125573
|
ramonjd
commented
Jan 2, 2026
ramonjd
commented
Jan 2, 2026
| [ blocks, hasClientIds ] | ||
| ); | ||
|
|
||
| const isHiddenAnywhere = useMemo( |
Member
Author
There was a problem hiding this comment.
This is kinda temporary to show icon states and what not. Later the UI will want to know where exactly the block is hidden, e.g., to display icons or other things.
ramonjd
commented
Jan 2, 2026
ramonjd
commented
Jan 2, 2026
| * if false, checks if hidden in any viewport. | ||
| * @return {boolean} Whether all blocks are hidden. | ||
| */ | ||
| export function areBlocksHiddenInViewports( |
Member
Author
There was a problem hiding this comment.
Answers the question: are the array of blocks hidden in any way. Same as above: tighten up.
ramonjd
commented
Jan 2, 2026
Contributor
|
Thank you, @ramonjd, for working on various enhancements to this feature! I've been reading through the related issues and PRs and finally understand the current state of the block visibility feature 😅 I'll take a closer look at the code next week, but overall it looks great. The first thing I noticed is that in the modal UI, it's hard to tell which viewports a block will actually be hidden in. In other words, it seems counterintuitive as to whether a check means show or hide: 
Can we change the UI according to the status, according to the mockup suggested here? This means we might need to make the following changes:
Another concern is when multiple blocks with different states are selected: the current logic is that if the selected blocks have mixed visibility states in the same viewport, the checkbox will not be checked. Perhaps we can use the indeterminate prop to represent intermediate states: 
Or, similar to the Block Lock feature, if the experimental setting is enabled, perhaps modal opening should only be allowed when a single block is selected. What do you think? |
Member
Author
Yes! Thank you for your thorough review. I'm going to give this PR the final polish and align with the designs.
Good point. This was something I wasn't sure about, so I just left it TBH 😄 I like the idea of an intermediary/indeterminate state - might help to have a tooltip or something as well? Anyway, let's try it out. Cheers! |
Member
Author
I have something working locally for this - requires a bit of special logic, and could result in screens like this: 
We can add some help text in there I guess to indicate what all this means (multiple blocks selection with mixed values). 
I'll save the commit, but I think it might be better to start off with one block at a time and work up from there in a separate PR. We can still keep the logic to handle multiple blocks in the modal, but just restrict it where the icons/buttons are to trigger the modal. |
Member
Author
I'll defer to folks on this - for now I've left the indeterminate state for testing purposes. |
ramonjd
force-pushed
the
add/viewport-block-visibility-modal
branch
from
3c45886 to
b980fbe
Compare
t-hamano
reviewed
Jan 6, 2026
packages/block-editor/src/components/block-visibility/use-block-visibility.js
Outdated
Show resolved
Hide resolved
ramonjd
force-pushed
the
add/viewport-block-visibility-modal
branch
from
7c944aa to
6b2a831
Compare
talldan
reviewed
Jan 7, 2026
Contributor
talldan
left a comment
talldan
left a comment
There was a problem hiding this comment.
It works nicely, but I have a slightly existential question over whether this should be a built-in block-editor feature or a WordPress extension to the block editor.
I guess it depends how the viewports are going to be configured. It might be that the configuration gets passed into the block editor (editor settings), and that adds this the viewport options to the block visibility feature.
The interface dependency is the biggest issue I see, I don't think it should be a dep of block editor. Usually it's purpose is for adding the chrome around the core block editor. You can probably look at how block locking has been implemented to resolve that, as the two features work very similarly.
packages/block-editor/src/components/block-settings-menu-controls/index.js
Outdated
Show resolved
Hide resolved
ramonjd
force-pushed
the
add/viewport-block-visibility-modal
branch
from
4d01b80 to
b97311e
Compare
ramonjd
commented
Jan 8, 2026
Comment on lines
+226
to
+229
| const canToggleBlockVisibility = | ||
| blocks.every( ( { clientId } ) => | ||
| hasBlockSupport( getBlockName( clientId ), 'visibility', true ) | ||
| ) && ! window.__experimentalHideBlocksBasedOnScreenSize; |
Member
Author
There was a problem hiding this comment.
Switching off hide/show commands for the experimental modal
Member
Author
|
This will need a light refactor after I'll look at it next week. |
t-hamano
reviewed
Jan 10, 2026
Contributor
t-hamano
left a comment
t-hamano
left a comment
There was a problem hiding this comment.
It looks almost ready to ship, and I'll test it again once this PR is rebased on top of the trunk branch.
packages/block-editor/src/components/block-visibility/use-block-visibility.js
Outdated
Show resolved
Hide resolved
ramonjd
force-pushed
the
add/viewport-block-visibility-modal
branch
from
b97311e to
a66e6a1
Compare
Member
Author
WIP PR: |
t-hamano
approved these changes
Jan 12, 2026
Contributor
t-hamano
left a comment
t-hamano
left a comment
There was a problem hiding this comment.
I tested it again and everything is working fine for me 👍
Contributor
|
Thanks for keeping at this. No blockers for this landing, but sharing a few thoughts to vet/keep an eye on when we test this in trunk, based on these screenshots. Notably: "hide from published content" is not necessarily a mixed-state value for the breakpoint values. While it's arguably best to check the "omit from published document" box when selecting all three breakpoints, I think it's crucial for us to remember the important difference between included vs. omitted from the DOM to prevent accidental leakage. Because of that, how would you feel about renaming "Hide from published content" to "Omit from published content"? "Hide" suggests it's still there. Separately, something to explore could be a different interface for this. An ASCII mockup from another thread: If what ships with this branch turns out to work well in casual testing, probably little to no action item, but it's top of mind for me to have a good plan for the omit/hide challenge, so users clearly know the difference. |
…ings, and update styles. Add modal, integrate visibility actions in block tools, and update related components for enhanced visibility control.
ramonjd
force-pushed
the
add/viewport-block-visibility-modal
branch
from
a66e6a1 to
047ed45
Compare
Member
Author
That would align the verb in the help text 👍🏻 I'll update that one line here before merge.
Ah, so a separate control fro the breakpoints? Could be worth a follow up to play in a future follow up. I think that has the potential to separate the idea of omit and hide as well. Thank you @jasmussen! |
ramonjd
added a commit
that referenced
this pull request
Jan 14, 2026
…tor conditional component exporting due to runtime race condition/build
This was referenced Jan 14, 2026
ramonjd
added a commit
that referenced
this pull request
Jan 16, 2026
…tor conditional component exporting due to runtime race condition/build
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?
Part of:
Requires:
Adds viewport-based block visibility (mobile, tablet, desktop) modal and other UI behind
window.__experimentalHideBlocksBasedOnScreenSizeflag.Important
The purpose of this PR is to reach a baseline for the interface to update a block's attributes, and triggers for displaying that interface. Things like colors/spacing/icons and anything that can be a follow up PR will likely be a follow up PR 😄
This PR also does not "tell" the block how to render itself on the canvas. #74025 takes care of that. Alternatively #74379
TODO
Modal features
Modal entry points
command palette (switched off for the experiment because the challenge of where to render the modal persists. See: Block visibility: add viewport modal and controls UI #74249 (comment)Cmd/Ctrl+K)Cmd/Ctrl+Shift+H) from canvas and list viewTesting Instructions
Enable experimental flag in
/wp-admin/admin.php?page=gutenberg-experimentsSome example HTML for you!
Test Modal Opening
Cmd/Ctrl+Shift+H→ Modal opensTest Modal Functionality
Test Multi-Block
Test Backward Compatibility
window.__experimentalHideBlocksBasedOnScreenSize = falseTest Edge Cases
Kapture.2026-01-08.at.15.52.22.mp4