Skip to content

Default icon actions to the compact size - #849

Open
morgmart wants to merge 2 commits into
mainfrom
morganm/compact-icon-default
Open

morgmart wants to merge 2 commits into
mainfrom
morganm/compact-icon-default

Conversation

@morgmart

@morgmart morgmart commented Oct 10, 2026 •

Copy link
Copy Markdown
Contributor

What this does

Make icon-only actions compact unless a caller deliberately chooses a larger size. Labelled buttons keep their medium default, and community navigation and the avatar edit badge retain their existing larger treatment.

This changes the actual shared component fallback, not a convention for agents. Existing callers that omit size receive the new small default; explicitly sized controls keep their current size.

Why it matters

Desktop utility actions repeatedly become oversized when size is omitted, even though the design guide already calls for compact toolbar, sidebar and header actions. The shared default now matches that common use instead of requiring every caller to remember an exception.

New rule: IconButton defaults to small (32px square with 16px artwork); Button continues to default to medium (40px minimum height).

How it works

The default changes in one shared owner, using the existing size tokens and interaction recipes. Three community-rail call sites and the avatar edit badge explicitly retain medium. Size aliases, colours, shapes, keyboard behaviour, loading/disabled states and pointer policy are unchanged.

The caller audit found 144 icon-button sites: 21 previously omitted size, 113 already chose compact sizes, eight chose extra-small, and two chose size by context. Eight utility actions visibly shrink: the moderation row menu, project copy-link action, workflow Refresh and actions menu, and four workflow remove/close utilities. Shell actions were already held at the compact size by host styling; the profile-menu avatar remains in its host-owned larger box. Composer controls, media playback and explicit identity sizes remain unchanged.

The audit also checked labelled-button callers. Their fallback is unchanged. The existing oversized workflow-creation tile uses a labelled Button with feature-owned geometry, so it is a separate adoption issue—not something this default change claims to fix. No alias cleanup, blanket shrinking or touch-specific sizing policy is included.

Verification

  • Default regression failed against the old owner for the intended medium-versus-small mismatch, then passed; explicit sizes and compatibility aliases remain covered.
  • All 148 design-system tests passed. App and design-system builds passed. Mandatory commit/push hooks passed: types, related unit tests, design type/contrast/adoption guards, and destination policy.
  • Complete affected avatar, plugin-import, sidenav and account-profile browser files passed in Chromium and WebKit (48 cases). The full workflow file also passed in both engines (62 cases).
  • Removing the medium exceptions made the rail and avatar regression checks fail in both engines; the exact owners were restored and both complete files passed (34 cases). No browser journey cases were added or removed; existing cases gained real host/CSS assertions.
  • The viewer's explicit/default size and loading/disabled case passed in both engines through an isolated temporary runner. The normal viewer command has an existing test-loader failure on an imported PNG; the runner extracted the checked-in case unchanged and exercised the real viewer. That broader runner issue is not changed here.
  • Shell and workflow-dialog inspection covered light/dark at narrow, intermediate and wide widths, keyboard menu dismissal/focus return, pointer activation and emulated touch. Shell sizing was additionally checked at 80% and 200% interface size. Screenshots below use synthetic fixture data.
  • All automatic CI, DCO and security checks passed on f5e5516bb (run). The latest automated source review requested no changes. Manual Windows validation was not requested and remains skipped; native packaged GUI, physical touch and human acceptance remain separate checks. buzz-review-completed is intentionally absent until human acceptance is confirmed.

CI paging-test follow-up

The original head and its rerun hit the existing five-second invitation-paging timeout. Main at the same base had already failed the same case (main run); PR #829 had previously split its combined paging/reset test. This follow-up changes one test file, not product behavior.

Bulk search input replaces per-keystroke simulation only in the two paging cases. Before checking the final row, they wait for the existing search-loading completion signal instead of repeatedly traversing and formatting the large result list while the row is absent. Real button clicks, real debounce/session, 96-result fixture, every page/reset/order/no-publication assertion, cancellation teardown, the five-second timeout and zero retries stay unchanged. No test cases were added or removed.

Local Apple Silicon macOS, pinned Vitest/jsdom, bin/pnpm exec vitest run src/bundled/channels/ChannelMembersDialog.test.tsx -t 'combined.*invitation', three runs on 3a0418e47 versus the test-only follow-up:

  • Paging: 2435/2412/2429ms → 1931/1918/1932ms (median about 20% faster).
  • Reset: 2650/2648/2711ms → 2227/2244/2226ms (median about 16% faster).
  • Complete owner file: 48/48 passed; final restored run 30.33s elapsed, 28.58s summed test execution; slowest cases were reset at 2.21s and paging at 1.73s. Setup/import and test times remain separately reported by Vitest.
  • Removing the refresh reset fails at 61 rows instead of 30; prematurely fetching the next relay page fails at 60 instead of 90. Both temporary mutations were restored byte-for-byte, then the complete file passed. Mongo and Spar independently reviewed the test-only follow-up and found no blockers.

Hosted verification now passes on f5e5516bb: all 4,668 shard-2 cases passed, including paging at 3.58s and reset at 3.74s, below the unchanged five-second limit. Shard wall time was 433.40s and summed test execution 545.53s; the paging file remained the slowest file at 45.97s. The previous hosted attempt reported 462.66s wall time, 588.83s summed execution and a 50.50s paging file, with both cases timing out at about 5.05s. These are separate hosted runs, not a controlled performance benchmark or a guarantee against future flakes. Mandatory push hooks also passed. Required human approval remains outstanding; no unresolved review threads are present.

Ready to try

In the feature preview, open a saved workflow and its actions menu. The utility icons should feel compact while Cancel/Save stay unchanged. Check the community rail and Edit avatar: their existing targets/artwork should remain unchanged. Try narrow layout and enlarged interface size, then confirm keyboard focus and Escape still return correctly.

Screenshots

Workflow editor, wide/light: compact utility menu; labelled footer actions unchanged.

Workflow editor with compact utility actions and unchanged labelled buttons

Workflow editor, narrow/dark: actions remain reachable and footer controls reflow.

Narrow workflow editor with compact icon actions and wrapping footer

Signed-off-by: morgmart <98432065+morgmart@users.noreply.github.com>
@morgmart
morgmart marked this pull request as ready for review October 10, 2026 23:18
@morgmart
morgmart requested a review from a team as a code owner October 10, 2026 23:18

@wesbillman wesbillman left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No actionable changes requested. The compact fallback reuses the existing size recipes, preserves the medium rail/avatar exceptions and labelled-button default, and adds coverage at the component and real-CSS layers.

Star Lord automated source review via Wes’s account; head 3a0418e472bacf9a77cdb9d4e0877cbe1b535066, base 37dcd836fbcf1613ddd27cece5a99e04d601bd64. I inspected affected callers, recovery/focus paths, the description and both screenshots without running code or tests; the CI snapshot still had JavaScript (2/2) in progress, and native/physical-touch and human acceptance remain unverified.

Signed-off-by: morgmart <98432065+morgmart@users.noreply.github.com>

@wesbillman wesbillman left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No changes requested on this test-only follow-up to the prior review. Bulk input and the existing busy-state completion barrier retain the paging/reset assertions, real debounce, and cancellation ownership.

Star Lord’s automated source review via Wes: head f5e5516bba9578035633e63e7a0ca3c9242b7bc6, base 37dcd836fbcf1613ddd27cece5a99e04d601bd64. No tests or apps were run; local timing improvements were not independently reproduced, hosted CI was still running at the snapshot, and native/physical-touch/human acceptance remains unverified.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants