Skip to content

fix(mobile): show a press on the phone toolbar and accessory keys - #737

Open
JDProfresh wants to merge 2 commits into
Ark0N:masterfrom
JDProfresh:fix/phone-press-feedback-1.46
Open

JDProfresh wants to merge 2 commits into
Ark0N:masterfrom
JDProfresh:fix/phone-press-feedback-1.46

Conversation

@JDProfresh

Copy link
Copy Markdown
Contributor

On every skin but og the skin block outranks the phone :active backgrounds of the toolbar buttons, so a tap on Run shows nothing at all and the other toolbar buttons show at most a faint tint that eases in over a 0.2s transition.

Problem

On my phone a quick tap on the toolbar or the accessory keys gives no sign that it landed. Measured in Chromium on 1.46.0 with a held press, on every skin no control changes transform or filter, and the background does not change at all for Run (in its default claude mode) on the six non-og skins, for the Run gear on the four light skins, and for Stop on og. Where a toolbar button's background does change, it is a small step (on the daylight skins the case button goes from 4% to 8% white, Stop to a 14% red tint) eased in over 0.2s, so a tap shorter than that shows only part of it. The voice, attach and settings icons and the accessory keys do keep their background press on the dark skins (the keys ease it in over 0.15s); the new press is added on top of it so every bar control answers the same way.

Cause

styles.css nests its skin block inside html:not([data-skin="og"]), so html:not([data-skin="og"]) .btn-toolbar (specificity 0,2,1) and its gradient Run rules beat the .btn-toolbar:active background and the Run button's claude and opencode :active colours in mobile.css regardless of load order. A background :active can only win there with !important, and an inset box-shadow loses to the skin's hover rules the same way.

What it does

  • Inside the existing (hover: none) and (pointer: coarse) block, a press on the toolbar buttons (.toolbar .btn-toolbar), the voice, attach and settings icons and the accessory keys scales to 0.94 and brightens (brightness(1.25)), over 80ms. Nothing on these buttons sets transform or filter at a higher specificity on any skin (the base .btn-toolbar:active nudge is 0,2,0 against 0,3,0 here), so one rule reads the same on all seven skins and no !important is needed.
  • The four light skins darken instead (brightness(0.9)), since brightening near-white reads as nothing.
  • Under prefers-reduced-motion: reduce the scale is dropped and only the tint stays.
  • Attach is matched through its wrapper (.btn-attach-mobile-wrap:active .btn-attach-mobile), because the press lands on the transparent file input laid over the button.
  • .toolbar .btn-toolbar keeps the rule off the modal buttons that also carry .btn-toolbar.
  • src/web/CLAUDE.md's skin-override note now says why the press is transform + filter and not a background.

Verified

Computed transform / filter on a held press, in the real app on a throwaway instance (440x956, touch, deviceScaleFactor 1), on Enter, Stop, Run, Run gear, case, voice, attach, settings and two accessory keys. Before is 1.46.0's mobile.css, after is this branch, same page otherwise. Every control read the same within a row.

Skin Before After After, reduced motion
og none / none scale(0.94) / brightness(1.25) none / brightness(1.25)
daylight-blue (default) none / none scale(0.94) / brightness(1.25) none / brightness(1.25)
daylight-green none / none scale(0.94) / brightness(1.25) none / brightness(1.25)
paper-gray none / none scale(0.94) / brightness(0.9) none / brightness(0.9)
solarized-light none / none scale(0.94) / brightness(0.9) none / brightness(0.9)
catppuccin-latte none / none scale(0.94) / brightness(0.9) none / brightness(0.9)
rose-pine-dawn none / none scale(0.94) / brightness(0.9) none / brightness(0.9)

At rest every control reads none / none in both. The page was asserted to be in the phone layout (Enter shown, Shell hidden, (hover: none) and (pointer: coarse) matching) for every run.

test/phone-press-feedback.browser.test.ts (new, browser suite, registered in BROWSER_TEST_GLOBS) renders the toolbar markup from index.html and the accessory bar template from keyboard-accessory.js with the real stylesheets in a touch Chromium context, holds a press on twelve controls and checks the exact transform and filter on all seven skins, plus reduced motion on one dark and one light skin. On 1.46.0's mobile.css all 9 of its tests fail; with this change all 9 pass.

On my iPhone 17 Pro Max (Safari) I have run this on my own install since 2026-10-21, and it works well: toolbar and accessory presses now visibly respond.

On every skin but og the skin block outranks the phone :active backgrounds of the toolbar buttons, so Run showed no press at all and the others at most a faint tint, eased in over their 0.2s transition, so a quick tap showed almost nothing. A press now scales and brightens (darkens on the light skins) over 80ms, two properties nothing on these buttons sets at a higher specificity, and honours prefers-reduced-motion.

A browser test presses every phone bar control on all seven skins and pins the computed transform and filter, so a later rule that takes the press away again shows up in the browser suite.
@Ark0N

Ark0N commented Oct 28, 2026

Copy link
Copy Markdown
Owner

Thanks @JDProfresh, this is a careful fix: the phone toolbar, the mobile voice/attach/settings icons and the accessory keys now show a press on every skin, using transform and filter so the press does not have to fight the skin block's background rules.

I checked it here: the new browser test fails 9/9 against 1.46.0's mobile.css and passes 9/9 with your change, the 80ms transition wins on all twelve controls on all seven skins, and the static checks and CI are green. The src/web/CLAUDE.md note explaining why this is transform + filter and not a background is exactly what the next person needs.

Nothing has to change before merge. Two optional touches if you are back in the file:

  • test/phone-press-feedback.browser.test.ts:100: the 250ms wait is longer than the old 0.2s transition, so the test would still pass if a later rule brought the slow transition back. Reading transitionDuration at rest and expecting 0.08s would pin it.
  • src/web/public/mobile.css:3490: transition: all 80ms ease also speeds up the other state changes on these buttons (Run's mode colours, Stop's confirming state, the armed Ctrl key). It is invisible at 80ms; listing transform, filter, background-color and border-color would keep the rule to the press.

Thanks again, and for running it on your own phone for a week before sending it.

`all` also sped up Run's mode colours, Stop's confirming state and the armed Ctrl key. The browser test now reads the transition at rest, since its 250ms hold would also pass the old 0.2s one.
@JDProfresh

Copy link
Copy Markdown
Contributor Author

Thanks, both are in f91cd34.

  • The test now reads transitionProperty and transitionDuration at rest on all twelve controls and expects transform, filter, background-color, border-color at 0.08s each. Against the old all rule it fails 9 of 9 on the property, and with the four durations set back to 200ms it fails 9 of 9 again.
  • mobile.css lists those four instead of all, with a few words added to the comment above the rule.

The browser test is 9 of 9 green, and the three gate files that read this part of mobile.css still pass.

@Ark0N

Ark0N commented Oct 28, 2026

Copy link
Copy Markdown
Owner

Thanks @JDProfresh, and thanks for the quick turnaround on f91cd34. This gives every phone toolbar button, the voice, attach and settings icons and the accessory keys a visible press on all seven skins, using transform and filter so it no longer fights the skin block's background rules.

I checked the new head: the browser test passes 9/9 here and still fails 9/9 against 1.46.0's mobile.css, the transition is now limited to the four properties you listed, and I also probed Run in its mode colours, Stop while confirming, the recording mic and the armed Ctrl key at phone and tablet widths. Every one presses the same way. Static checks and CI are green.

Nothing to change. This is ready to merge as it stands.

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