fix(kimi-web): full-width chat column, Ctrl+Enter steering, code block line numbers - #2369
fix(kimi-web): full-width chat column, Ctrl+Enter steering, code block line numbers#2369Tolik-Trek wants to merge 7 commits into
Conversation
The reading column was capped at 760px, leaving wide empty margins on large screens. Let it follow the pane width instead.
…dialog preventDefault ran only while a turn was running, so an idle Ctrl+S/Cmd+S fell through to the browser and opened the Save Page dialog. Always swallow the shortcut; steering still only fires when a turn is running.
🦋 Changeset detectedLatest commit: b059278 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7e44ece315
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| --read-max: 760px; | ||
| /* The reading column follows the pane width — no fixed max-width cap, so | ||
| wide windows don't leave empty margins on both sides. */ | ||
| --read-max: 100%; |
There was a problem hiding this comment.
Keep regular chat content capped by the reading token
As committed, --read-max: 100% makes regular assistant prose and user bubbles expand to 94%/78% of whatever desktop pane width is available, while the web design-system view still defines --p-content-max as the chat reading-column max width and states that regular chat prose stays within that 760px column. On large monitors this regresses readability and also bypasses the tokenized layout contract; if full-width prose is intended, the design-system contract should be updated together, otherwise keep the normal stream capped and reserve wider growth for the existing table/content exceptions.
AGENTS.md reference: apps/kimi-web/AGENTS.md:L11-L11
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Good catch — at that commit the design-system contract indeed lagged behind the change. It has been updated since (6edc9c0): --p-content-max no longer documents the chat reading column (it now only backs the xl dialog width), and the design-system view's chat/wide-tables sections were rewritten to state that the chat column follows the pane width with no fixed cap, including the outline rail's new anchor at the pane's right edge. Full-width prose is the deliberate behavior change of this PR — the readability trade-off on very wide monitors is accepted on purpose.
With the reading column no longer capped at a fixed width, the outline rail's old anchor (the 760px column edge) left it floating in the middle of the widened content. Pin the rail to the pane's right edge inside the scrollbar gutter, reveal labels leftward over the content on hover, and measure the expanded fit in that direction.
…e Page The composer's keydown only fires while the composer is focused, so a Ctrl+S/Cmd+S pressed anywhere else still fell through to the browser's Save Page dialog. A capture-phase preventDefault in App.vue's global keydown now swallows the shortcut everywhere; steering stays in the composer's handler.
Plain-text code blocks rendered without the container wrapper nest <code> deeper than pre > code, so the inline-code chip rule (font: .9em) applied inside them and shrank the code to 10.8px/normal while the line-number overlay stayed at 12px/18px — the numbers drifted progressively below their lines. Extend the font:inherit guard to all markstream pres.
|
@codex review |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c1eab7977c
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| stable outside position left; labels reveal leftward over the content. | ||
| Tables that reach the rail temporarily hide it via the occlusion hit-test | ||
| in ConversationPane, so the overlap is safe. */ | ||
| right: calc(var(--panes-scrollbar-width, 0px) + var(--space-2)); |
There was a problem hiding this comment.
Avoid placing the TOC hover bridge over messages
With the rail now anchored inside the pane edge, its existing invisible hover bridge (left: -14px plus the right-side extension) sits over the right edge of full-width chat content; for example right-aligned user bubbles end near the pane edge, so clicks or text selection in the vertical band around the TOC are intercepted by the nav instead of the message. This only happens when the TOC is enabled and a message crosses the rail’s vertical range, but it makes ordinary chat content non-interactive there; either keep the rail outside the content, reserve padding, or make only the actual TOC rows receive pointer events.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Addressed in d78caaf: the hover bridge is removed entirely — only the actual outline rows receive pointer events now, so clicks and text selection along the pane's right edge reach the messages underneath. The expanded rows are wide enough targets once the panel is open, so the bridge was no longer pulling its weight.
| <h3 class="sub">Unified message stream</h3> | ||
| <div class="stage-wrap"> | ||
| <div class="stage-bar"><span class="st">Conversation · 760px reading column</span></div> | ||
| <div class="stage-bar"><span class="st">Conversation · full-width column</span></div> |
There was a problem hiding this comment.
Make the design-system demo match full-width chat
Fresh evidence since the earlier review is that this renamed stage now says “full-width column”, but the demo rendered immediately below is still .demo-chat with max-width: 560px, so the canonical design-system overlay continues to show a capped chat column even though the product layout was changed to full width. Future visual checks against this spec can therefore approve the old narrow layout; update this demo’s cap (or scope it away from the chat stream example) so §04 reflects the new behavior.
AGENTS.md reference: apps/kimi-web/AGENTS.md:L11-L11
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in d78caaf: dropped the 560px cap from .demo-chat, so the §04 demo renders the chat stream at the full stage width, matching the renamed "full-width column" stage.
…demo The rail's invisible hover bridge sat over the right edge of full-width content and intercepted clicks and text selection from the messages beneath it; only the actual outline rows receive pointer events now. Also drop the 560px cap from the design-system chat demo so the spec matches the full-width behavior.
Chrome Canary intercepts Ctrl+S for the Save Page dialog before the page can preventDefault it, so the advertised steer shortcut was unusable there. Ctrl+Enter / Cmd+Enter now steers into the running turn and falls through to the normal submit path when idle; the app-wide Ctrl+S swallow is gone since the app no longer uses that shortcut.
Related Issue
None — the problems are explained below.
Problem
Three annoyances in the browser web UI (
kimi web):preventDefault()while a turn was running and the composer had focus, and Chrome Canary intercepts Ctrl+S for the Save Page dialog before the page can handle it at all.<code>deeper thanpre > code, so the inline-code chip rule (font: .9em) shrinks the code to 10.8px/normal while the line-number overlay keeps 12px/18px.What changed
font: inheritguard for code inside code blocks now covers all markstreampreelements (via thedata-markstream-preattribute), not only those inside the container wrapper, keeping the code and the line-number overlay on the same font metrics.All changes are confined to
apps/kimi-web. Verified:typecheckclean,test653/653 passed,check:styleintroduces no new findings. The line-number fix was additionally verified live in the browser (dev server + measurement of number/code line geometry before and after).Checklist
gen-changesetsskill, or this PR needs no changeset.gen-docsskill, or this PR needs no doc update.