Zwei Ursachen, warum es auf der Tickets-Seite nicht ging (am echten Firefox/Chromium
gegen die Live-App verifiziert):
1) Tab ging verloren: der gewählte Filter-Tab (z. B. „Geschlossen") war reiner
Component-State und sprang nach „Zurück" (Remount) auf „Offen" zurück — also war man
in der falschen, kurzen Liste. Jetzt wird der Tab in der Session gemerkt und
wiederhergestellt (userPicked startet weiterhin false, damit ?focus=-Deep-Links
weiter funktionieren).
2) Scroll-Save-Heuristik zu unzuverlässig: Beim Wegnavigieren schrumpft der Inhalt von
.app-main → der Container klemmt auf eine kleinere Position → dieses scroll-Event
überschrieb die gemerkte Stelle. Erkennung präzisiert: nur verwerfen, wenn Position
UND scrollHeight gleichzeitig SINKEN (= Inhalt geschrumpft/Seitenwechsel). Eine echte
Nutzer-Scrollung verkleinert die scrollHeight nie — damit kein fälschliches Verwerfen
echter Positionen mehr (vorherige „Höhe geändert"-Heuristik schluckte zu viel).
Tests: scroll-restore.spec erweitert (realistisches 2-Schritt-Scrollen + Tickets-Tab
überlebt Zurück), desktop+phone grün; vitest 149 grün.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Deckt die Regression ab, die zuletzt durchrutschte:
- Liste scrollen → Tier öffnen → Browser-Zurück → Position bleibt erhalten.
- Position überlebt App-Hintergrund/Wiederanzeige (visibilitychange).
Läuft im phone-Projekt (390x844, Touch) UND desktop, am echten Scroll-Container .app-main.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
