diff options
| author | Christophe Besson <cbesson@gmail.com> | 2026-08-26 01:36:27 +0200 |
|---|---|---|
| committer | Christophe Besson <cbesson@gmail.com> | 2026-08-26 01:36:27 +0200 |
| commit | badbdd2635e62637fc03003e3115fd5b2391dba2 (patch) | |
| tree | 7566a85720d628072a58939b9377013c4d07f96f /docs/cast-smart-tv.md | |
| parent | 52707f6280bb268102cd60e692c0199a45caf35e (diff) | |
| download | meshbay-badbdd2635e62637fc03003e3115fd5b2391dba2.tar.gz | |
fix(hub): stop hover/focus states from sticking on mobile touch
A tap on a touchscreen fires a synthetic hover with no "pointer left"
to end it, and leaves the tapped element genuinely focused (unlike a
desktop click) — so any :hover-styled button looked permanently
"pressed" until something else was tapped, and any plain <button> with
no custom hover at all (the nav hamburger) showed the browser's default
focus ring for the same reason. Not reproducible on desktop, which
actually has a mouse to move away with. Found live on mobile Chrome,
2026-08-26 — most visible on the music player's next/prev/shuffle
buttons, but the same mechanism affects any button in the app.
Two small, general fixes rather than a per-button patch:
- `:focus:not(:focus-visible) { outline: none; }` in the global reset —
clears a lingering focus ring from a pointer/touch interaction while
leaving real keyboard-navigation focus untouched.
- `.music-player-btn`/`.music-player-play`'s :hover rules scoped inside
`@media (hover: hover)`, so a touch tap never triggers them at all.
Only the two reported, confirmed cases are touched here — the same
`@media (hover: hover)` wrap applies to any of the stylesheet's other
:hover rules if the same stickiness shows up elsewhere.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013XSohfUQQiaE77qyFLgSv3
Diffstat (limited to 'docs/cast-smart-tv.md')
0 files changed, 0 insertions, 0 deletions