2026-07-13 OpenRouter Interceptor Continue-Message Shortcut

What I set out to do

Asked whether the extension had an ALT/Option+ENTER keybind to continue the last bot message on JanitorAI. It did not, and I initially doubted JanitorAI even had a continue affordance. It does: a fast-forward button on each settled assistant message. A diagnostic capture settled the question.

What I actually did

Read the capture (2026-07-13T21-27-42-134Z-diag-captures.json) via the using-captures skill. diagnostic.pageControls listed the button outright: aria-label="Continue this message", class _controlPanelButton_4evg7_13, 11 instances on the page alongside 17 Edit buttons. The class names are hashed, so aria-label is the only stable hook — same lesson as the swipe buttons.

Built the shortcut TDD, shipped as d6ea40b:

  • findBotMessageControl(doc, control) in src/utils/janitorai-carousel.ts. Resolves a control-panel button ("Edit" | "Continue this message") on the last bot message. Inside botChoicesContainer every swipe variation stays mounted, so it picks the one actually on screen by bounding rect, with a first-variation fallback for unmeasured rects.
  • ALT+ENTER handler in janitorai-shortcuts.ts, gated on the main composer being focused and empty (same gate ARROWUP uses), so it can never fire mid-typing. Calls stopPropagation() as well as preventDefault() so JanitorAI’s own ENTER handler never sees the keystroke and cannot also try to send.
  • DRY: the ARROWUP “edit last bot message” shortcut carried its own ~100-line copy of that same variant walk. It now shares the helper.

Tests written first, watched fail on findBotMessageControl is not a function: 5 unit tests (happy-dom, with getBoundingClientRect stubbed to fake the carousel viewport) plus test/playwright/janitorai-continue-message.spec.ts covering the gate — fires on empty input, blocked with text, blocked when unfocused, plain ENTER does not continue.

What was striking

  • The capture’s pageControls summary is a genuinely good UI-affordance index: one look answered “does this button exist and what is its selector,” a question that would otherwise mean digging through DOM dumps. That is the payoff of 2026-07-11 OpenRouter Interceptor Capture Cap and Settings Rewiring’s diagnostic bundle work.
  • Behavior change worth remembering: ARROWUP used to walk backwards for the newest bot message that had an Edit button. Now it targets the newest bot message and stays inert if that message has no Edit button — i.e. while a reply is still streaming. This matches how the swipe shortcuts already behaved, and it is the better semantic, but it is a change.
  • happy-dom reports empty rects for everything, which means any “is it visible” logic collapses to false there. Hence the explicit first-variation fallback: without it, the shortcut would be a dead key in any pre-layout render rather than merely imprecise.
  • Same day, same theme as 2026-07-13 SillyTavern Continue Fixed by Turning Prefill Off: continuing an assistant message keeps being the thing I want and keeps being the thing that is broken or missing.

Verification

vitest 361 pass (24 files, +5 new) · Playwright continue spec 8 pass (Chromium + Firefox) · arrow-keys spec 10 pass after the refactor · lint/typecheck clean.