Files
kandev/apps/web/hooks/use-editor-keybinds.test.ts
T
João Salavisa 99dfbbde58 feat(plugins): add keybindings and modal window capabilities (#1895)
* feat(plugins): add keybindings and modal window capabilities

Add two independent plugin UI capabilities.

Keybindings: plugins declare keybindings in the manifest under
ui.keybindings ({id, default, description}), validated backend-side
(combo grammar + unique ids, requires a UI bundle) and exposed to the
frontend. Plugin JS binds a handler via registry.registerKeybinding(id,
handler); a global dispatcher fires it. Combos are user-overridable in
Settings > Keyboard Shortcuts (namespaced plugin:{pluginId}:{id}) with
conflict detection against core and other plugins.

Modals: host.openModal({title?, content, size?, dismissible?}) returns a
{ close() } handle and renders in a single host-owned Dialog isolated by
PluginErrorBoundary, cleaned up on plugin unload.

Fixture plugin, PLUGIN-API.md / spec, and a Playwright e2e demonstrate a
keybinding handler opening a modal.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(plugins): address review feedback on keybinding dispatch and validation

Core shortcuts now take precedence over plugin keybindings on a colliding
combo (defaultPrevented cooperation between the two capture-phase
dispatchers), a throwing plugin handler no longer aborts dispatch to other
plugins, and the keybinding combo grammar is tightened: the backend validator
and frontend parser both drop the undocumented control/super modifier
aliases and reject shift+digit/symbol combos that can never actually fire
(KeyboardEvent.key reports the shifted character, not the token).

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(plugins): stop conflicting core shortcut from double-firing with plugin keybindings

The earlier defaultPrevented guard only covered the central useAppShortcuts
dispatcher. Per-component core shortcuts registered via useKeyboardShortcut
run in the bubble phase, after the capture-phase plugin keybinding dispatcher,
so a plugin-handled-and-prevented combo still triggered the core action too.
Guard useKeyboardShortcut (and use-editor-keybinds, another capture-phase core
listener) on event.defaultPrevented so exactly one action fires per combo.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(plugins): make core shortcuts always win over plugin keybindings

Panel-search, task-switcher, and other core listeners never checked
event.defaultPrevented, so a plugin bound to the same combo (e.g. Cmd/Ctrl+F)
could still fire alongside them. Instead of patching every core listener,
usePluginShortcuts now computes the set of effective core shortcut combos
(registry, resolved through user overrides, plus FIND_IN_PANEL/SAVE) and
skips invoking any plugin handler whose combo is in that set, so the
matching core listener always handles the event exactly once.

Also adds a hook-level regression test for useEditorKeybinds' existing
defaultPrevented guard, and fixes a leaked capture-phase window listener in
use-keyboard-shortcut.test.ts that could bleed into later tests.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* fix(web): keep Cmd+K closing the command panel after shortcut-precedence guard

cmdk's built-in vim bindings intercept Ctrl/Cmd+K and +P as list-navigation
shortcuts and call preventDefault() before the event reaches our window-level
useKeyboardShortcut listeners. Once that hook started bailing on
event.defaultPrevented (added to fix core/plugin shortcut double-firing), the
palette's own Cmd+K close/reopen toggle got silently suppressed whenever focus
was inside the open panel. Disable cmdk's vim bindings on the command palette
so its Ctrl/Cmd+K and +P always reach the app-level toggle.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

* docs(plugins): document keybindings and modal window plugin APIs

Fill in the public author-facing docs that the internal plugin-keybindings
and modal-window contract (PLUGIN-API.md, spec.md) already covers: the
registry.registerKeybinding / host.openModal JS surface, the ui.keybindings
manifest field with its combo grammar, and a capability mention on the
Plugins overview page.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Kandev Agent <agent@kandev.dev>
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2026-07-24 11:45:28 +01:00

102 lines
3.7 KiB
TypeScript

import { describe, it, expect, vi, afterEach } from "vitest";
import { renderHook, cleanup } from "@testing-library/react";
import type { DockviewApi } from "dockview-react";
const mockToggleAppSidebar = vi.fn();
const mockToggleBottomTerminal = vi.fn();
vi.mock("@/components/state-provider", () => ({
useAppStoreApi: () => ({
getState: () => ({
userSettings: { keyboardShortcuts: {} },
bottomTerminal: { isOpen: false },
toggleAppSidebar: mockToggleAppSidebar,
toggleBottomTerminal: mockToggleBottomTerminal,
tasks: { activeTaskId: null, activeSessionId: null },
environmentIdBySessionId: {},
}),
}),
}));
import { useEditorKeybinds } from "./use-editor-keybinds";
import { useDockviewStore } from "@/lib/state/dockview-store";
function pressKey(
key: string,
init: KeyboardEventInit = {},
target: EventTarget = window,
): KeyboardEvent {
const event = new KeyboardEvent("keydown", { key, bubbles: true, cancelable: true, ...init });
target.dispatchEvent(event);
return event;
}
/**
* Minimal fake `DockviewApi` exercising only the tab-navigation branch of
* `useEditorKeybinds`: two panels in the active panel's group, so
* `handleTabNavigation` can find the "next" panel and call its
* `api.setActive()`.
*/
function makeFakeApi(activateSpy: (id: string) => void): DockviewApi {
type FakePanel = { id: string; api: { setActive: () => void }; group?: { panels: FakePanel[] } };
const panelA: FakePanel = { id: "panel-a", api: { setActive: () => activateSpy("panel-a") } };
const panelB: FakePanel = { id: "panel-b", api: { setActive: () => activateSpy("panel-b") } };
const group = { panels: [panelA, panelB] };
panelA.group = group;
panelB.group = group;
return {
activePanel: panelA,
} as unknown as DockviewApi;
}
describe("useEditorKeybinds", () => {
afterEach(() => {
cleanup();
useDockviewStore.setState({ api: null });
mockToggleAppSidebar.mockClear();
mockToggleBottomTerminal.mockClear();
});
it("does not run the editor action (tab navigation) when the event is already defaultPrevented", () => {
// Regression: `useEditorKeybinds`'s capture-phase handler guards on
// `event.defaultPrevented` so a combo already handled by another
// capture-phase core dispatcher or a plugin keybinding doesn't also run
// the editor's tab-navigation/terminal-toggle logic (double action for a
// single keypress). This exercises that guard directly, at the hook
// level, rather than only through `useKeyboardShortcut`.
const activateSpy = vi.fn();
useDockviewStore.setState({ api: makeFakeApi(activateSpy) });
// Register this capture-phase listener BEFORE mounting the hook so it
// runs first (capture-phase listeners on the same target fire in
// registration order) — mirroring a real prior capture dispatcher (a
// core shortcut or plugin keybinding) that already handled the event.
const preventDefaultListener = (event: KeyboardEvent) => {
event.preventDefault();
};
window.addEventListener("keydown", preventDefaultListener, { capture: true });
renderHook(() => useEditorKeybinds());
try {
pressKey("]", { ctrlKey: true, shiftKey: true, code: "BracketRight" });
expect(activateSpy).not.toHaveBeenCalled();
} finally {
window.removeEventListener("keydown", preventDefaultListener, { capture: true });
}
});
it("runs the editor action (tab navigation) for a non-prevented matching event", () => {
const activateSpy = vi.fn();
useDockviewStore.setState({ api: makeFakeApi(activateSpy) });
renderHook(() => useEditorKeybinds());
pressKey("]", { ctrlKey: true, shiftKey: true, code: "BracketRight" });
expect(activateSpy).toHaveBeenCalledWith("panel-b");
});
});