You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Source: https://www.andreamirandasalas.com/ (a Wix site; full-screen "MENU" popup opened by a three-line hamburger). Versions: DLA 0.8.9, SSI 1.20.9, Blocks Engine php-transformer 0.26.8, WordPress 7.1.2, Studio trunk 2ae57f71. Local Studio import, headless Chromium at 1440×900.
User-reported symptom: the menu opens, but its close "X" does nothing, and the hamburger is hard to hit.
Capture (website/index.html and every route): the source hamburger is three separate line-shaped buttons that all open the same popup (data-popupid="nso43", aria-haspopup="dialog", aria-label="", empty label span). Each one became its own <details class="dla-disclosure"> with its own <summary> and its own full copy of the dialog panel. So one popup ended up as 3 disclosures, 3 panel copies, and 3 summaries with no accessible name.
Imported WordPress, measured:
The summaries are the three hamburger lines: rects 58,41,61×2, 67,52,44×2, 75,63,27×2. Only a click landing exactly on a 2px line opens the menu. On /my-approach one of the three lines is covered by a sibling <details> and can't be hit at all, and a click between lines does nothing.
Once open, the visible "X" at ~(67,113) is a plain <img alt=""> (no link, button or handler). Clicking it leaves the open state unchanged (010 → 010). Escape closes the menu (DISCLOSURE_RUNTIME keydown handler).
The only working close is the injected open-state summary style (static-dialogs.ts:23-24: [open]>summary{position:fixed;right:1rem;top:1rem;…} + summary:after{content:"Close"}). It does reach WordPress through the stylesheet bundle, but the summary keeps the source button's own width/offset. It renders as a 1466×29 white bar at left:-42px, so its "Close" text sits off-screen to the left and the bar looks empty. Clicking the bar does close the menu.
At 390px the user reports the same behaviour. I haven't reproduced it headlessly: the menu couldn't be opened there, because the visible icon is an <a> without href and the core/navigation "Open menu" button is visibility:hidden.
:126-164 (trigger-opened dialogs): for each state, findTriggers() returns every matching trigger, and each trigger is replaced by its own <details> + <summary> + panel copy. Triggers that open the same dialog aren't grouped. The summary label falls back from aria-label to trigger text, and when both are empty no data-dla-disclosure-label is set, even though the dialog's own aria-label ("MENU") is known.
:177-190 + findCloseControl():262-285: only initial dialogs look up the dialog's own verified close control and turn it into the working summary. Trigger-opened dialogs never wire their in-panel close control, so it stays inert.
Expected
A trigger-opened dialog captured as a disclosure closes through its own visible close control, and its trigger keeps the source's full hit area and an accessible name. None of this should depend on injected CSS that downstream importers may not carry or may override.
Triggers that open the same dialog (same controlled target/popup identity) share one disclosure and one panel copy, and the summary covers the whole trigger group's box rather than a single line.
When the dialog contains a close control (label/aria-label matching close, a dismiss attribute, or the control verified during capture), mark it (for example data-dla-disclosure-close) and have the disclosure runtime close the owning <details> when it's clicked or activated with the keyboard. Make it focusable/operable with a name, for example "Close MENU".
Acceptance: a neutral fixture with three sibling icon-only buttons (aria-label="") that open one role="dialog" aria-label="Menu" containing an <img alt=""> close icon inside a close button. The capture yields one disclosure, and the summary box covers all three buttons. At 390 and 1440 the menu opens by clicking anywhere in the trigger area and closes by clicking the in-panel close icon, both in the capture and after WordPress import. The regression fails before the fix.
Reproduction
Source: https://www.andreamirandasalas.com/ (a Wix site; full-screen "MENU" popup opened by a three-line hamburger). Versions: DLA 0.8.9, SSI 1.20.9, Blocks Engine php-transformer 0.26.8, WordPress 7.1.2, Studio trunk 2ae57f71. Local Studio import, headless Chromium at 1440×900.
User-reported symptom: the menu opens, but its close "X" does nothing, and the hamburger is hard to hit.
Capture (
website/index.htmland every route): the source hamburger is three separate line-shaped buttons that all open the same popup (data-popupid="nso43",aria-haspopup="dialog",aria-label="", empty label span). Each one became its own<details class="dla-disclosure">with its own<summary>and its own full copy of the dialog panel. So one popup ended up as 3 disclosures, 3 panel copies, and 3 summaries with no accessible name.Imported WordPress, measured:
58,41,61×2,67,52,44×2,75,63,27×2. Only a click landing exactly on a 2px line opens the menu. On/my-approachone of the three lines is covered by a sibling<details>and can't be hit at all, and a click between lines does nothing.<img alt="">(no link, button or handler). Clicking it leaves the open state unchanged (010→010). Escape closes the menu (DISCLOSURE_RUNTIMEkeydown handler).static-dialogs.ts:23-24:[open]>summary{position:fixed;right:1rem;top:1rem;…}+summary:after{content:"Close"}). It does reach WordPress through the stylesheet bundle, but the summary keeps the source button's own width/offset. It renders as a 1466×29 white bar atleft:-42px, so its "Close" text sits off-screen to the left and the bar looks empty. Clicking the bar does close the menu.<a>withouthrefand the core/navigation "Open menu" button isvisibility:hidden.Code path (origin/main 02c0cf1)
src/lib/static-dialogs.ts:126-164(trigger-opened dialogs): for eachstate,findTriggers()returns every matching trigger, and each trigger is replaced by its own<details>+<summary>+ panel copy. Triggers that open the same dialog aren't grouped. The summary label falls back fromaria-labelto trigger text, and when both are empty nodata-dla-disclosure-labelis set, even though the dialog's ownaria-label("MENU") is known.:177-190+findCloseControl():262-285: only initial dialogs look up the dialog's own verified close control and turn it into the working summary. Trigger-opened dialogs never wire their in-panel close control, so it stays inert.Expected
A trigger-opened dialog captured as a disclosure closes through its own visible close control, and its trigger keeps the source's full hit area and an accessible name. None of this should depend on injected CSS that downstream importers may not carry or may override.
aria-labelmatching close, a dismiss attribute, or the control verified during capture), mark it (for exampledata-dla-disclosure-close) and have the disclosure runtime close the owning<details>when it's clicked or activated with the keyboard. Make it focusable/operable with a name, for example "Close MENU".aria-label, then the trigger text, then the dialog's accessible name. That also removes the empty<summary>behind core/details built from a text-less summary is invalid in the editor (save yields empty <summary>) blocks-engine#2365.Acceptance: a neutral fixture with three sibling icon-only buttons (
aria-label="") that open onerole="dialog" aria-label="Menu"containing an<img alt="">close icon inside a close button. The capture yields one disclosure, and the summary box covers all three buttons. At 390 and 1440 the menu opens by clicking anywhere in the trigger area and closes by clicking the in-panel close icon, both in the capture and after WordPress import. The regression fails before the fix.Related: Automattic/blocks-engine#2256 (inert mobile "Open Menu" trigger after import), #446 and #399 (closed; button/anchor-button menu capture).
AI assistance
Claude Code (Claude Opus 5.5) reproduced this on a local Studio import, verified the code path, and drafted this issue.