💎 PREMIUM: WordPress/gutenberg/pull/ - HD Photos!
{{ message }}
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
youknowriad
requested review from
ajitbohra,
ellatrix and
fabiankaegy
as code owners
youknowriad
added
[Type] Enhancement
github-actions
bot
added
[Package] Block library
|
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: +158 B (+0.01%) Total Size: 2.58 MB
ℹ️ View Unchanged
|
youknowriad
requested review from
juanmaguitar and
tellthemachines
as code owners
youknowriad
changed the title
|
I transformed it to a block support and enabled it in list and social icons. |
youknowriad
added
[Block] List
|
I like this:
|
There was a problem hiding this comment.
✅ Tested and looking good for me for List, Social Links and Buttons
I'm currently reviewing the experimental Form Block, which could also greatly benefit from this to add the Form Inputs in this list format (I'm having Elementor a lot in mind for this block, ngl)
I'm wondering if we could abstract this list inspector control subcomponent also from Navigation
Probably this kind of list would require some degree of customization depending on the block, just like Navigation list has.
|
There's an issue #73866 for this, so I've updated the PR description to make this PR close it. |
|
Some feedback from testing. If you have the main List View open alongside the inspector List View, it becomes impossible to open the dropdown menus for the items. It looks like clicking one of them tries to open both menus: Kapture.2025-12-22.at.16.04.46.mp4I notice the navigation block has its own menu, maybe this is why! I think the Button blocks could have better list view labels, it's hard to tell them apart (possibly the same for list items too?): The navigation block also has a little back arrow in the block card which makes it possible to get back to the parent, that might also be useful for these other blocks: |
|
@talldan The fix for the first issue is basically a revert of this PR #54083, which I just did and I don't see any issues really with the revert, I can't really reproduce the bugs mentioned. @talldan I agree for the button labels. I wonder if I should push it here or keep it on its own PR since it's slightly a tangent. On the last item as well, it seems today it's hard-coded and the behavior is also not clear. Should apply to any nested block like the navigation block does, ... Happy to open a dedicated PR about it as well. |
youknowriad
force-pushed
the
add/list-tab-buttons-block
branch
from
8a6e737 to
d6f3a61
Compare
|
Flaky tests detected in 4e90ed1. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20454648487
|
This was referenced Dec 22, 2025
@youknowriad I see this does reintroduce the bug. To replicate, switch on the "allow right click overrides" preference in the editor settings, then with another window focused, right click into the list view on different list items within your editor window and you'll get this: 
What's expected is that if one dropdown menu is opened and you right click into another one, the first one would be closed. Note that this bug only occurs when the browser window does not have focus, as focus will never be placed within the dropdowns. While this sounds like an edge case, back when we landed #54083 it was because it's surprisingly common on MacOS for folks to switch between browser windows and interact with a window before shifting focus to it. Things have changed a fair bit in Gutenberg since 2023, though, so perhaps there's another way we can fix that? |
I think this is the root issue, if you right click, the focus should move to the dropdown and if you click elsewhere, the dropdown should close. |
|
@andrewserong So it turns out that for security reasons, browsers prevent you from programmatically focusing a window or elements in that window when the window is not already focused (avoid click highjacking). For me this means that we shouldn't take over "right click" when the window is not focused. This is what my last commit does. |
|
I think that works pretty nicely. The only time I see a slight confusion is if I try right clicking on the unfocused browser window, it brings the window to the front, but it doesn't focus it, I have to left click as well (on mac os). I think it's ok though, I don't expect many people will be doing that. |
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.
Related #73845
Fixes #73866
What?
Removes the allowlist restriction for the List View inspector tab, making it available to any block that provides list group fills. The Buttons block now includes list view support, allowing users to reorder buttons through a hierarchical interface in the sidebar.
Why?
Previously, only the Navigation block could show the List View tab due to a hardcoded allowlist. This prevented other container blocks like Buttons, Social Icons, and List from benefiting from the same reordering and management interface. This limitation was inconsistent with how other inspector tabs (Settings, Styles, Content) work, which appear automatically based on available fills.
Testing Instructions
Select a Buttons block and verify the List View tab appears in the inspector sidebar and is selected by default. Confirm you can reorder buttons via drag-and-drop in the list view and add new buttons using the appender. Select a Paragraph block and verify it defaults to the Settings tab. Select a Navigation block and confirm it still defaults to List View as before.