Menu settings and path alias details should be closed even with values

The last time the exact codepath that causes the element to open was #2406103: Remove hook_node_validate() and hook_node_submit() because they bypass the entity API. I related the issues..

The form array has an #open element indicating this behavior could be intentional.

This is what I mean about the intention.

Applied patch #5 on 9.2.x and it works fine.Adding screenshots below.

Before patch:

After patch:

Verified and tested patch #5.
Patch applied successfully and looks good to me.

Testing Steps:
# Goto: Appearance -> Apply Seven Theme
# Goto: Any Content and Edit it
# Click on the "Menu Settings" arrow and check the box for "Provide a menu link"
# Save it and again edit the content
# The menu settings field group in the meta panel starts expanded if a menu link has been provided

Expected Results:
# After applying Patch #5, the User should not see the menu settings have been expanded if a menu link has been provided.

Actual Results:
# Currently, The menu settings field group in the meta panel starts expanded if a menu link has been provided.

Please refer attached screenshots for the same.
Looks good to me.
Can be a move to RTBC.

Let's get a test for this,

Doing a triage of my new component menu_ui

This one seemed pretty basic and added test coverage. Updated summary using the first set of images uploaded. Fixed the credit too.

The patch does what is advertised. Personally, I always thought the open was a feature. I feel like we need a usability review on this.

This...is inconsistent with the other field groups in the meta panel which remain closed unless expanded.

That isn't entirely true. The path alias group is open if there's an alias. Again, to me it's a feature.

depending the decision here would say we should open a novice one for the path alias group too. We have the summary so closing by default makes sense.

We discussed this issue at #3568606: Drupal Usability Meeting 2026-01-30. That issue will have a link to a recording of the meeting. I am adding issue credit for the participants: @pallavi singh3013, @rkoller, @simohell, and @the_g_bomb.

Usability review

We discussed this issue at #3568606: Drupal Usability Meeting 2026-01-30. The recording of the meeting: https://youtu.be/80LmftxqFSk. The attendees at the usability meeting were @pallavi singh3013, @rkoller, @simohell, and @the_g_bomb.

We've first looked at the status quo, using the example of a node edit page for an article content type which has the largest number of detail elements in the advanced sidebar. When creating a new node all the detail elements are collapsed. When editing an existing node there are some inconsistencies. After the default setting is changed and saved, the details elements for the Menu settings, Comment settings, and URL alias are getting expanded on reopen, while the detail elements for Authoring information and Promotion options remain collapsed. It was also noted that the detail element for Comment settings is missing a detail summary reflecting the current active setting like the rest of the detail elements.

The group had a clear consensus that the state for all the available detail elements should be consistent, either all collapsed or all expanded, the current inconsistent behavior is not a desirable goal from our perspective.

One downside of making all detail elements expanded is a rather high vertical height past the fold. With all detail elements expanded the advanced sidebar also sort lacks of a clear visual structure, it is kind of hard to distinguish the detail summary and the detail wrapper, making it hard to process. And most importantly it has to be kept in mind that the settings for a node are not necessarily changed on a regular basis.

The settings are most often set on node creation and then rarely adjusted. That was the reason we've initially thought about the idea of expanding all the detail elements on node creation while keeping them closed when editing a node. But we've decided against that idea due to the aforementioned increased vertical height and the increased cognitive load for the case of all detail elements expanded.

The user has the situational awareness with the detail summaries and the additional clicks for expanding detail element(s) are bearable - an adjustment remains a deliberate step.

So in summary we are in line with the proposed resolution keeping all the detail elements collapsed. The only addition we would like to recommend is to add a detail summary for Comment settings, so it displays the default setting Open - but that should probably better go into a follow-up issue.

I'll set the issue back to needs work, cuz when testing MR14519 and making changes to every setting in the advanced sidebar the comment settings and url alias remained expanded.

If you want more feedback from the usability team, a good way to reach out is in the #ux channel in Slack.

Thanks for the detailed write up! I'm not opposed to expanding the scope to the path_alias module to get the same behavior. I would say the comment settings could probably go into a follow issue because it'll need the detail summary too. Tagging for that.

Thank you to the Usability team for their detailed perspective on the issue.

Opened the related issue for comments and pushed change for including path section. Should be good now.

thank you for opening the followup and the changes on this MR! just quickly pulled the latest changes, and all detail elements except the comment settings remain collapsed after i've changed all the available default settings in the advanced sidebar for a new node. and after the "close by default" for the comment settings detail element should be covered within the follow up per the issue title of the followup, this issue looks good to go from a manual testing perspective. i leave it at needs review so someone else can also take a final look at the code changes.

I'm not crazy about the check for the aria-expanded attribute on the summary in the tests in order to verify this is working as intended. That attribute is set by details-aria.js, not by native functionality. It's like a third party in this testing scenario. That feels like something that we shouldn't rely on for testing. Is there a reason that the open attribute on the <details> isn't being checked instead? That's the attribute we're changing with this patch after all.

Sure switched it up

Thank you for considering my feedback. Unfortunately, the selectors are targeting the wrong element now.

My feedback was addressed. This looks good to me.

This is a nice small improvement. 🙌 Committed!