chat-duo-web tablet residuals: touch-target coverage + on-screen-keyboard overlap (MSG-171 #2/#3)

Sub-tickets

Activity

• wi-cli-venus created · 5w ago
• wi-cli-venus statusChanged · 5w ago
  0.7.70 shipped (a6621ad). #3 done in code, #2 premise corrected - item stays open on browser verification only. #3 ON-SCREEN-KEYBOARD OVERLAP - FIXED. index.html body is now height:var(--app-h,100dvh), driven from visualViewport.height by a hook beside queueScrollToBottom (:651). Also clamped #body max-height to max(60px, calc(30dvh - var(--kb-inset,0px))) - without that the textarea still sizes against the FULL viewport and re-pushes the controls row + send button off-screen, the same failure main#feed min-height:0 was added to fix; a bare calc() would go negative and be dropped as invalid, silently reverting. The inset is computed from window.innerHeight (layout viewport = what dvh resolves to), so a browser that already shrinks it for the keyboard yields ~0 and nothing is subtracted twice. Engages only past 80px and excludes pinch-zoom (scale>1 also shrinks vv.height). Props are removed, not zeroed, on close. No visualViewport => hook returns and rendering is byte-identical to 0.7.69. NOT loopback-verifiable - needs a real tablet, which is why this is inProgress and not done. #2 TOUCH TARGETS - item premise is wrong; correcting it rather than executing it. '7 of ~20' counted textual var(--tap) occurrences, not coverage. index.html:61-68 is a BLANKET select,input,textarea,button{min-height:var(--tap)}: every interactive element is 44px unless explicitly opted out. 11 opt-outs exist (min-height:0 at :116 .pm-picker, :264 .copy-btn, :274 .reply-toggle, :286 .godview-reply-box button, :318/:319/:326 style panel, :344 .contact-actions, :370 .contact-reply-box, :396 .eq-actions, :407 .eq-answer-box) - all compact secondary controls inside message cards or panels where 44px breaks the card, so applying --tap to them is a layout regression. They stay; this note is the record of why. One genuine miss: .msg .copy-btn was ~32px and is a PRIMARY per-message action - padding widened 8px->12px (~40px box), which moves nothing because it is absolutely positioned. No further code change owed on #2.
• wi-cli-venus statusChanged · 5w ago
  0.7.72 shipped. Audit (audit-llmmsgsrv-cc, re a6621ad/0.7.70) returned no defects on #3 and confirmed the #2 correction, with one exception I accepted: .msg .reply-toggle was mischaracterized as a secondary control. It sits in the same absolutely-positioned per-message top-right corner as .copy-btn and reply is a primary triage action, so ~31px was the same defect copy-btn had. padding 5px 10px -> 14px 12px, ~39px against copy-btn's ~40px. The other 10 opt-outs stand as secondary; .contact-actions is per-card, not per-message. #2 is now complete - no further code owed. Item remains inProgress on #3 ONLY, pending confirmation on a real tablet. The keyboard path is not reachable from loopback (curl has no viewport and bypasses Caddy), so a green deploy is not evidence here. What to check on the device: open the compose textarea, confirm the send button and the pulldown row stay visible above the keyboard, confirm the feed is still scrollable while the keyboard is up, and confirm pinch-zoom does not collapse the shell.
• wi-cli-venus statusChanged · 5w ago
  0.7.73: #2 had a regression - the two enlarged tap targets overlapped. .copy-btn (absolute, right:4px, padding-derived ~40px width) vs .reply-actions (absolute, hardcoded right:30px): Reply's right edge sat ~14px inside the copy button, same y-band, no z-index, copy-btn appended last so it won the strip - a tap on the right edge of Reply copied instead. Fixed by making the size font-independent: copy-btn is now width:40px/height:40px/padding:0 flex-centered, and .reply-actions moved to right:48px (4 + 40 + 4px gap). Hit areas unchanged, they no longer collide. Also closed the desktop-regression question on #3 without a browser: the keyboardInset IIFE was extracted and driven as a pure function with stubbed visualViewport/innerHeight - desktop idle, desktop scrolled, a 40px chrome collapse, pinch-zoom at scale 2, and an already-shrunk layout viewport all removeProperty and never set --app-h/--kb-inset; only a real keyboard (900 layout / 520 visual) sets them. The hook is live at every width, so that mattered. STILL DEVICE-ONLY and why this stays inProgress: whether the keyboard layout is USABLE. On the tablet - open the compose textarea, confirm the send button and the pulldown row stay visible above the keyboard, confirm the feed still scrolls with the keyboard up, confirm pinch-zoom does not collapse the shell, and confirm Reply and Copy in a message's top-right corner now hit their own targets.
• wi-cli-venus completed · 4w ago
  DEVICE-VERIFIED AND CLOSED. Elazar ran all five checks on the tablet against 0.7.73 (version read off the footer before testing, so the result is attributable to a build): all pass. 1) Reply tapped at its right edge opens the reply box, does not copy - the 0.7.72 overlap regression is gone. 2) Copy copies. 3) Send button and pulldown row stay visible above the on-screen keyboard - this is #3, the item the row existed for, and the only one that could never be reached from loopback because curl has no viewport. 4) Feed still scrolls with the keyboard up. 5) Pinch-zoom does not collapse the shell. #2 (touch targets) was already complete in code at 0.7.72. Both MSG-171 residuals are now done. No code owed by anyone.