Repository navigation
fix(mobile): show a press on the phone toolbar and accessory keys - #737
JDProfresh wants to merge 2 commits into
Conversation
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.
|
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 Nothing has to change before merge. Two optional touches if you are back in the file:
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.
|
Thanks, both are in f91cd34.
The browser test is 9 of 9 green, and the three gate files that read this part of |
|
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 Nothing to change. This is ready to merge as it stands. |
On every skin but og the skin block outranks the phone
:activebackgrounds 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.cssnests its skin block insidehtml:not([data-skin="og"]), sohtml:not([data-skin="og"]) .btn-toolbar(specificity 0,2,1) and its gradient Run rules beat the.btn-toolbar:activebackground and the Run button's claude and opencode:activecolours inmobile.cssregardless of load order. A background:activecan only win there with!important, and an insetbox-shadowloses to the skin's hover rules the same way.What it does
(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:activenudge is 0,2,0 against 0,3,0 here), so one rule reads the same on all seven skins and no!importantis needed.brightness(0.9)), since brightening near-white reads as nothing.prefers-reduced-motion: reducethe scale is dropped and only the tint stays..btn-attach-mobile-wrap:active .btn-attach-mobile), because the press lands on the transparent file input laid over the button..toolbar .btn-toolbarkeeps 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/filteron a held press, in the real app on a throwaway instance (440x956, touch,deviceScaleFactor1), on Enter, Stop, Run, Run gear, case, voice, attach, settings and two accessory keys. Before is 1.46.0'smobile.css, after is this branch, same page otherwise. Every control read the same within a row.At rest every control reads
none / nonein 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 inBROWSER_TEST_GLOBS) renders the toolbar markup fromindex.htmland the accessory bar template fromkeyboard-accessory.jswith 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'smobile.cssall 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.