Skip to content

feat(web): add configurable chat view width - #4353

Open
PattaraS wants to merge 1 commit into
mainfrom
chat-view-width
Open

feat(web): add configurable chat view width#4353
PattaraS wants to merge 1 commit into
mainfrom
chat-view-width

Conversation

@PattaraS

@PattaraS PattaraS commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Related issue

N/A — no issue number was provided.

Summary

  • Adds a persisted Chat width setting under Settings → Appearance with Normal, Wide, and Extra-wide options.
  • Applies the selected width consistently to the transcript, assistant messages, status rows, composer, and related chat surfaces.
  • Resets the preference with the rest of Appearance settings and initializes it for standalone and embedded app entry points.

ELI5: The chat column was fixed to a narrow size. This adds three simple width choices so users can give the conversation more room without manually resizing anything.

Settings → Appearance → Chat width
             ↓
      localStorage preference
             ↓
  --chat-column-max-width CSS variable
             ↓
 transcript + composer + chat surfaces

Test Plan

  • Added unit coverage for preference normalization, persistence, CSS application, and default reset behavior.
  • Added SettingsPage coverage for selecting and persisting Extra-wide.
  • Prettier check passed for all changed files.
  • git diff --check passed.
  • Full pre-commit could not complete because the checkout lacks .venv and web dependencies; the affected hooks reported missing executables (.venv/bin/python, web Prettier/Oxlint/TypeScript tooling).

Demo

Settings control:

Appearance settings showing Normal, Wide, and Extra-wide chat width options

Chat view comparison at a wide desktop viewport (2560px):

Normal

Normal chat width

Wide

Wide chat width

Extra-wide

Extra-wide chat width

The comparison uses the same conversation and viewport; only the selected chat width changes. The PR review deployment can be used to verify the live behavior.

Type of change

  • Bug fix
  • Feature
  • UI / frontend change
  • Refactor / chore
  • Docs
  • Test / CI
  • Breaking change

Test coverage

  • Unit tests added / updated
  • Integration tests added / updated
  • E2E tests added / updated
  • Manual verification completed
  • Existing tests cover this change
  • Not applicable

Coverage notes

Automated tests cover the preference helpers and Appearance selection. Manual browser verification is deferred to the PR review deployment because local frontend dependencies are unavailable in this checkout.

Changelog

Users can choose Normal, Wide, or Extra-wide chat content from Appearance settings.

@github-actions github-actions Bot added the size/M Pull request size: M label Aug 7, 2026
@omnigent-ci

omnigent-ci Bot commented Aug 7, 2026

Copy link
Copy Markdown
Contributor

Polly AI Review

Missing visual demonstration

This is a user-visible UI change — it adds a new "Chat width" picker under Settings → Appearance and alters the width of the transcript/composer/chat surfaces. The PR description's Demo section says a demonstration is "Not available in this environment," and no screenshots or video are attached. Please add before/after screenshots (or a short clip) of the Appearance settings control and the chat column at Normal / Wide / Extra-wide so reviewers can confirm the layout without checking out the branch.

Blocking issues

None. The preference plumbing is correct: applyChatViewWidth is called before first paint in both main.tsx (standalone) and embed.tsx; readChatViewWidth/writeChatViewWidth are SSR-safe (typeof window/document guards) and swallow localStorage errors; the CSS fallback (48rem) matches the normal value so a fresh session renders identically to the old default; and the reset path both rewrites the preference and clears the omnigent:chat-view-width key. The .chat-column-width rule is a plain CSS class in index.css, so it isn't subject to Tailwind purging.

Security vulnerabilities

None identified. Input is confined to a fixed enum (normal/wide/extra-wide) that is normalized on read and write, and the only sink is a CSS variable set to a hardcoded rem value — no injection surface.

Non-blocking notes

  • Responsive auto-widening on large monitors is lost. The old constant was max-w-3xl min-[1921px]:max-w-4xl min-[2561px]:max-w-5xl, which automatically widened the column to 4xl (≈56rem) at ≥1921px and 5xl (≈64rem) at ≥2561px. The new .chat-column-width resolves to a fixed 48rem by default (Normal), so existing users on wide/ultrawide displays will silently get a narrower column than before unless they manually pick Wide/Extra-wide. The new options happen to map to the same 56rem/64rem values, but the adaptation is no longer automatic. Consider preserving responsive behavior for the Normal setting (e.g. keep the breakpoint bump as the default --chat-column-max-width, or via min-[…] overrides) or at least call this behavior change out in the changelog.
  • AssistantBubble fold comment. The retained comment still references "the ordinary chat-column cap" — fine — but note the non-wide branch now depends on the CSS variable rather than a static class; if the variable is ever unset on a subtree, the max-w-3xl-equivalent fallback only applies because the class carries var(..., 48rem). This is correct as written; just flagging the coupling.

Summary

A clean, well-scoped feature: the preference module is small, guarded, and tested, and it's wired consistently through both app entry points, the settings control, and the reset path. The one substantive concern is a behavioral regression — the previous automatic column-widening on large/ultrawide monitors is replaced by a fixed default that only widens when the user opts in — which is worth either preserving or documenting. Please also attach a visual demo of the new setting and the resulting widths.


Automated review by Polly · workflow run

Signed-off-by: Pat Sukprasert <pattara.sk127@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

size/M Pull request size: M ui-preview

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant