Focus is lost on dialog close if the opener is inside a collapsible element

MR works for contextual links and dropbuttons.
Test coverage covers dropbuttons, but still needs contextual links.

Dialog support could potentially be added here as well.

bnjmnm → closed merge request !3976

Moving to NW to get the feedback + #3 addressed. On a high level the approach seems fine.

Adding WCAG SC tag https://www.w3.org/WAI/WCAG21/Understanding/keyboard

Addressed MR feedback and added test coverage for contextual links.

Looks good to me. Manually tested with layout builder contextual links and dropbutton in /dialog_renderer-collapsed-opener and works as expected.

Committed d6bb006 and pushed to 11.x. Also cherry-picked to 10.1.x. Thanks!

lauriii → closed merge request !3977

This seems to have introduced a (not so) random test failure: 🐛 [random test failure] ContextualLinksTest::testContextualLinksClick Closed: outdated

Reverted due to the randomly failing tests.

FWIW: Whilst the issue was still in Core, it seems to have a ~40% chance of ending up with the activeElement being the whole body.
(See https://www.drupal.org/project/drupal/issues/3357583#comment-15076521 📌 [Ignore] In space (and/or this issue), no one can hear patches scream V Closed: outdated and one of the failure screenshots attached)

It looks like the contextual links trait force-opens the links in a way that does not reliably set the opener property in the dialog. So instead of force-opening, the contextual link is made visible by hovering (the way it would to a real user).

Tested the new patch with layout builder contextual links and dropbutton in /dialog_renderer-collapsed-opener and works as expected.

Thanks for getting the random fail sorted! Crediting @Spokje for reporting and investigating the random failure.

Committed d8f747b and pushed to 11.x. Cherry-picked to 10.1.x. Thanks!

Automatically closed - issue fixed for 2 weeks with no activity.