Add detail description to the comment settings and close by default

Working on this

thank you for working on the MR @ben280398. one detail that directly strikes the eye is that the styling for the detail description is not consistent and in line with the rest of the detail descriptions in the advanced sidebar.

and the MR needs a rebase after the issue (#2982853: Menu settings and path alias details should be closed even with values) this one is the followup for got committed today

So I see a good green pipeline but I also see it 'Needs work'... Im confused here (Im a beginner)...
Please could anyone tell just with of a bit clarity that what needs to be done in this situation?
Im guessing maybe there is no error in code but in styling?

Adds a drupalSetSummary to the Comment settings details element, following the same pattern as Menu settings and URL alias. The summary reflects the current commenting status (Open/Closed/Hidden) by reading the checked radio button label, and the element is collapsed by default.

Done rebasing. Changing this for review.

added a screenshot for the current state in the main branch to illustrate the before state against the already added after state. also added the defaults if expanded or collapsed by default.

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because it is a well-defined issue. What's left to do is to confirm the fix works, and address the concern about the proper place to leave the test.

The Drupal Contribution Mentoring team is triaging issues for DrupalCon Chicago 2026 and we are reserving this issue for Mentored Contribution during the event. After 2026-03-27, this issue returns to being open to all. Thanks!

Testing in branch drupal-3571616-01

extend> added comments module

structure> added comment type name "Lissette Test Comment Type" and assigned target>entity type>content
structure> assigned comment field to content type 'article'
create>article

Tested in Windows 10, Chrome and on Edge
expected result "open" should appear underneath Comment settings.

To add to the confusion, this change was working when javascript aggregation is disabled, but not when enabled. Tested with chrome (Version 146.0.7680.165) and firefox 148.0.2 (aarch64) on macos (26.3.1). When I removed the compiled files from the filesystem it was working.

there is a fundamental problem in the first place it looks like. if you do a drush cr after you did a git pull checking out the latest changes i get an error:

$> ddev clear

In TaggedHandlersPass.php line 185:
                                                                                                                     
  Service 'Twig\Extra\Html\HtmlExtension' for consumer 'twig' does not implement Twig\Extension\ExtensionInterface.  
                                                                                                                     

Failed to run drush cr: exit status 1

maybe the rebase still isnt completely done and needs some additional fixing?

p.s. ddev clear i use in that output snipper is simply an alias that executes drush cr and then removes any css and js cache files

@rkoller -- look at this MR (https://git.drupalcode.org/project/drupal/-/merge_requests/15224) -- I started a new branch and new MR

Updated `origin/main` today, so the MR only shows three changes.

hm odd. i tried the new MR before but i got an error on checkout so i thought i would already be on the new MR. but checkout to MR15224 worked now after another try (drupal-3571616-01) but i still get the very same error about TaggedHandlersPass.php in line 185 when i run drush cr :/

Update: Oh looks like that error with the TaggedHandlersPass.php also happens on the main branch.

I think I may have found the fix, but I want to do a bit more testing to confirm it.

The main change was simplifying the radio button selector in comment-entity-form.js on line 22.

Before, it was more restrictive:
'input[type="radio"][name^="field_comment"][name$="[status]"]:checked, input[type="radio"][name^="comment"][name$="[status]"]:checked'

I changed it to:
'input[type="radio"][name$="[status]"]:checked'

My current thinking is that the original selector was too narrowly targeted. It only matched fields whose names started with comment or field_comment. So if the comment field used a different name, like field_comments in Umami, querySelector() would return null, which caused the summary to come back empty.

Because the details element already limits the scope to the comment widget, selecting any checked radio ending in [status] should be safe and should cover all comment field name variations.

Created a new branch drupal-3571616-02 based on @partyka's work in drupal-3571616-01. Changes include:

• CommentWidget.php: The comment settings details element is now always closed by default (#open => FALSE) instead of comparing against field default values to determine open/closed state.
• comment-entity-form.js: Rewrote the summary behavior to use a more robust CSS selector ([class*="comment-"][class*="-settings-form"]) and querySelector instead of jQuery's .next('label'). This supports both field API comment fields and built-in comment status inputs.
• CommentFieldsTest.php: Added testCommentWidgetDetailsClosedByDefault() functional test to verify the details element is closed regardless of comment status.

Ready for review.