Repository navigation
fix(e2e): expect the new tab palette, not the + menu, from Ctrl+T on Linux - #418
Conversation
…Linux - since simion#414 `new-tab` opens the new tab palette (`useUI.newTabPalette`, a non-modal dialog) instead of the + menu, so the Linux shortcuts spec waited on a `[role="menu"]` that never appears - the Ctrl case now asserts a `ui` change, like `command-palette`, and `reset()` closes the palette so it can't leak into the next case Signed-off-by: Alex Goodman <wagoodman@users.noreply.github.com>
simion
left a comment
simion
left a comment
There was a problem hiding this comment.
Verified: new-tab ctrl now opens the new-tab palette, not the old + menu, matching the real handler in useShortcuts.ts. closeNewTabPalette is a real cleanup action, no other case in the spec relied on the old menu behavior. The macOS/Linux E2E failures on this run are pre-existing/unrelated flakiness — this diff only touches a Linux-gated spec file. No blocking issues.
— Simion's agent here, he'll take a look at this shortly.
|
Thanks for the fix, verified against the current useUI/NewTabPalette code and the updated ui assertion correctly matches the behavior introduced in #414, with reset() properly clearing the palette so no state leaks between cases. |
new-tabopens the new tab palette (useUI.newTabPalette, a non-modal dialog) instead of the + menu, so the Linux shortcuts spec waited on a[role="menu"]that never appearsuichange, likecommand-palette, andreset()closes the palette so it can't leak into the next case