UI: drop tab-bar tap highlight; don't slide the first screen on launch #45
Reference in New Issue
Block a user
Delete Branch "feature/ui-tap-startup-polish"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Two small UI polish items (follow-up to #44).
Tab-bar tap highlight
Tapping a bottom-tab icon flashed a background — the icon square's
:activepress tint plus the default WebKit tap flash (the same pair removed from the lobby rows in #44). Dropped the press tint and set-webkit-tap-highlight-color: transparenton.tab. The selected-tab highlight (Settings / Comms hubs) is kept.No slide on launch
The route pane's
in:slideXis local to its{#key}block, so it plays on that block's own first mount whenapp.readyflips — the lobby slid in on launch as if navigated into from another screen. Gate the slide duration to 0 for the first pane shown after boot (astartedflag set right after it mounts), so launch is static while every later route change animates as before.Tested
pnpm check(0 errors) +build+ e2e (100, Chromium + WebKit). The tap flash is native (WKWebView) — best verified live in iOS Telegram, along with the static launch.Tab bar: tapping a bottom-tab icon flashed a background — the icon square's :active press tint plus the default WebKit tap flash, the same pair removed from the lobby rows. Drop the press tint and set -webkit-tap-highlight-color: transparent on .tab. The selected-tab highlight (Settings / Comms hubs) stays. Startup slide: the route pane's in:slideX is local to its {#key} block, so it plays on that block's own first mount when app.ready flips — the lobby slid in on launch as if navigated into from another screen. Gate the slide duration to 0 for the first pane shown after boot (a `started` flag set right after it mounts), so launch is static while every later route change animates as before.The first attempt (the App.svelte `started` gate) targeted the first pane mount, but the slide is a second render. On a Telegram cold launch the URL fragment is Telegram's #tgWebAppData=... launch params, which the router parsed as notfound; bootstrap's navigate('/') then corrected it to the lobby asynchronously, re-keying the route pane (notfound -> lobby) and sliding the lobby in as if returning from a screen. A reload was static because the hash was already #/. Treat a Telegram launch fragment as the lobby root in the router, so the route is correct from the first pane (no re-key, no slide). Extract the pure hash->Route parsing into routeparse.ts so it unit-tests without a DOM, and revert the gate (the first pane never slid — local transitions skip the initial mount, as clean browser launches showed). Tests: routeparse unit tests (incl. the tgWebApp fragment); an e2e that launches with the fragment in the URL and asserts the lobby plus the normalised #/ hash.