Move note View session and Edit actions to overflow menu below sm

What does this MR do and why?

The View session and Edit buttons crowd the comment header at narrow widths forcing names to wrap awkwardly. This MR moves those actions into the comment's overflow (ellipsis) menu when the comment is narrower than the sm breakpoint, matching where we drop the role badges (this approach varies by context)

Each surface measures a different container, because each surface's role badges are already keyed to a different one:

Surface	Component	Container	Inline buttons	Overflow menu group
Work item comments	work_items/components/notes/work_item_note_actions.vue	note-container (the comment's timeline <li>)	note-hidden-xs	note-only-xs
MR overview discussions and legacy issue notes	notes/components/note_actions.vue	panel	gl-hidden @sm/panel:gl-inline-flex	@sm/panel:gl-hidden
Rapid diffs discussions	rapid_diffs/app/discussions/note_actions.vue	discussion	@max-sm/discussion:gl-hidden	@sm/discussion:gl-hidden

On each surface, the inline buttons use the same container and breakpoint as that surface's role badges, and the menu group uses the exact opposite. The actions never show twice, and they're never missing.

What's not in this MR

This exposes some of the problems with the current comment components — three separate implementations, all doing roughly the same job, requiring three updates. This doesn't try to refactor this, but it seems necessary to consider at some point.

Full agent description

The work item classes (note-hidden-xs, note-only-xs) are not reused on the other two surfaces. Those rules only apply inside .work-item-notes .note-container-query-wrapper, which is the only place that sets container-name: note-container. Rapid diffs uses its own timeline_entry_item.vue, which doesn't have that wrapper. Outside it, neither class hides anything, so the inline buttons and menu items would both show at every width. The two new surfaces only use existing Tailwind container-query variants, and this MR adds no SCSS for them. All four variants show up in the output of tailwindcss -c config/tailwind.config.js.

Work item details. note-only-xs is the exact opposite of note-hidden-xs, and both are defined in the same note-container block in _notes_base.scss. Above sm, note-only-xs sets display: none. When the comment is narrow, it sets no display value, so GlDisclosureDropdownGroup keeps its own display. For browsers without solid container query support, work_items.scss adds a fallback for note-only-xs next to the existing note-hidden-xs one.

Legacy notes details. The inline buttons use gl-hidden @sm/panel:gl-inline-flex, which is the same pattern as the role badges (gl-hidden @sm/panel:gl-block), with inline-flex to match GlButton's own display. Because it's the same pattern, the buttons behave exactly like the badges even where there's no panel container. The inline Edit button keeps its js-note-edit class. The menu item calls the same onEdit handler as the inline button. It closes the menu the same way the other items in this menu do (through the dropdown's default auto-close).

Rapid diffs details. The menu keeps its existing v-else-if placement after the inline Delete button, like legacy notes. The inline Delete button only shows when noteUrl is empty, which never happens for a saved comment, so no extra menu is needed there. The Edit comment item emits the same start-editing event as the inline button.

Why sm of each surface's own container: an earlier version of this MR used the md breakpoint of the global panel container (@md/panel:) for work items. That's a different breakpoint on a different container than the work item role badges use. Now the actions move into the menu at exactly the width where the badges hide, on every surface.

ViewSessionButton gets a new asDropdownItem prop. With it, the component renders a GlDisclosureDropdownItem instead of a GlButton. The menu item uses the same Duo

availability check and emits the same SHOW_SESSION event as the button. All three surfaces use it.

Nothing changes when the comment is sm wide or wider.

References

• Closes #631274

Screenshots or screen recordings

Before	After
	same

After, by surface (1280px viewport and 480px viewport with the overflow menu open)

Surface	Wide	Narrow
Work item comment
MR overview discussion
MR diff discussion (rapid diffs)
Commit diff discussion (rapid diffs)

How to set up and validate locally

For View session on any surface, use a comment created by a Duo agent session, with Duo Chat available.

Work item comments

1. Open a work item that has comments you can edit.
2. At a wide viewport: View session and Edit show inline in the comment header, and they are not in the ellipsis menu.
3. Shrink the viewport, or open the work item in the side panel, until the comment is narrower than sm (576px). The role badges and both inline buttons disappear at the same width, and View session and Edit comment show at the top of the ellipsis menu. Both items work.

Merge request overview discussions and legacy issue notes (notes/components/note_actions.vue)

1. Open the Overview tab of a merge request that has comments you can edit.
2. At a wide viewport: View session and Edit show inline, and they are not in the ellipsis menu.
3. Shrink the viewport until the page's panel container is narrower than sm (576px). The role badges and both inline buttons disappear at the same width, and View session and Edit comment show at the top of the ellipsis menu. Edit comment opens the comment editor.

Rapid diffs discussions (rapid_diffs/app/discussions/note_actions.vue)

1. Open a merge request diff with rapid diffs enabled, and find a diff discussion with a comment you can edit.
2. At a wide viewport: View session and Edit show inline, and they are not in the ellipsis menu.
3. Shrink the viewport until the discussion is narrower than sm (576px). The role badges and both inline buttons disappear at the same width, and View session and Edit comment show at the top of the ellipsis menu. Edit comment opens the comment editor.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.