fix(ai-agent): claim mod+backslash only while the panel holds focus - #307
Closed
maksimzinchuk wants to merge 1 commit into
Closed
fix(ai-agent): claim mod+backslash only while the panel holds focus#307maksimzinchuk wants to merge 1 commit into
maksimzinchuk wants to merge 1 commit into
Conversation
Closes VCST-5746. Built on the VCST-5632 branch, which touches the same component. The panel consumed `mod+\` whenever it was open, so while the assistant was up there was no keyboard route to maximize a blade at all -- even with focus demonstrably inside one. That contradicts the targeting model the shell settled on in VCST-5680: a blade shortcut acts on the blade holding focus. The chord is now claimed only when `document.activeElement` is inside the panel; otherwise the event is left alone and the blade dispatcher handles it. Escape is untouched -- consuming it while the panel is open is what keeps the blade behind from closing. Measured live: focus in the middle blade maximizes that blade and leaves the panel at 362px; focus on the panel's own Maximize control expands the panel to 500px and maximizes no blade; Escape from the host still closes the panel with all three blades intact. One caveat for whoever reads the tests: focus *inside the chat iframe* never reaches the host at all -- the keystroke goes to the iframe's own document, same barrier as VCST-5673. So the branch covering the iframe element is unreachable in a browser; it passes in jsdom only because there is no cross-origin boundary there. Expanding the panel from the keyboard while the chat has focus needs the VirtoOz-side relay.
|
📦 Preview published for commit Install the preview with dist-tag: npm install @vc-shell/framework@pr-307Or pin to the exact commit: npm install @vc-shell/framework@2.4.0-pr307.72245d2Published packages (dist-tag
|
maksimzinchuk
added a commit
that referenced
this pull request
Aug 19, 2026
…310) Closes VCST-5746. Replaces #307, which GitHub auto-closed when its base branch (`fix/VCST-5632-popup-reopen-and-inert`) was deleted on merge of #306. The branch has since been rebased onto `main`, so it now carries only its own commit. ## Problem The panel consumed `mod+\` whenever it was open, so while the assistant was up there was **no keyboard route to maximize a blade at all** — even with focus demonstrably inside one. That contradicts the targeting model the shell settled on in VCST-5680: a blade shortcut acts on the blade holding focus. ## Change The chord is claimed only when `document.activeElement` is inside the panel; otherwise the event is left alone and the blade dispatcher handles it. Escape is untouched — consuming it while the panel is open is what keeps the blade behind from closing. ## Verified live | Focus location | Result | | --- | --- | | Control in the middle blade, panel open | that blade gains `vc-blade--maximized`; panel stays `362px` | | Panel's own Maximize control | panel `362px` → `500px`, `--expanded`; no blade maximized | | Host, panel open | Escape closes the panel, all 3 blades intact — unchanged | ## One caveat about the tests Focus *inside the chat iframe* never reaches the host at all — the keystroke goes to the iframe's own document, the same barrier as VCST-5673. So the branch covering the iframe element is unreachable in a browser; it passes in jsdom only because there is no cross-origin boundary there. Do not read that test as proof of browser behaviour. Expanding the panel from the keyboard while the chat has focus needs the relay filed as VirtoCommerce/virto-oz#17. ## Verification `407 files / 3830 tests` green on this branch, rebased onto current `main`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes VCST-5746.
Problem
The panel consumed
mod+\whenever it was open, so while the assistant was up there was no keyboard route to maximize a blade at all — even with focus demonstrably inside one. That contradicts the targeting model the shell settled on in VCST-5680: a blade shortcut acts on the blade holding focus.Change
The chord is claimed only when
document.activeElementis inside the panel; otherwise the event is left alone and the blade dispatcher handles it. Escape is untouched — consuming it while the panel is open is what keeps the blade behind from closing.Verified live
vc-blade--maximized; panel stays362px362px→500px,--expanded; no blade maximizedOne caveat about the tests
Focus inside the chat iframe never reaches the host at all — the keystroke goes to the iframe's own document, the same barrier as VCST-5673. So the branch covering the iframe element is unreachable in a browser; it passes in jsdom only because there is no cross-origin boundary there. Do not read that test as proof of browser behaviour.
Expanding the panel from the keyboard while the chat has focus needs the chat-side relay that VCST-5673 describes.
Verification
403 files / 3802 testsgreen on this branch.