Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

PWA: diagnose and fix WebKit Sign out stalling before the auth POST

Chiusa
  • Qualcosa non va?
#461 1 commento 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@Zamojski5 ci sta già lavorando.

Dal 10/10/2026.

  • #470 di @Zamojski5 — integrata

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Outcome and scope

Under #20 (MOB-1, MOB-4, MOB-5, MOB-7), ordinary Sign out must not stall before the authentication POST, including during first service-worker installation. Preserve the existing session, push and account-cache privacy contract in docs/product/mobile-pwa.md; this is separate from the two map corrections in PR #380.

Owner: @Zamojski5 (existing PWA owner). Independent evaluator: @PelikanFix16. Milestone 2, accepted brief. Contract proposed for the owner/evaluator to accept or name concrete gaps once; no founder approval queue.

Dated observed evidence — 2026-10-10

  • PR #380 pre-correction product head 4cbc5dd20b2b39a7821504bafc258ed8b2292ce3, composed with main 4697fadc077adc39f1ebbce12c9ae46a5a0f74d7: Chromium 44 affected tests passed; WebKit map-connect 9 passed, but test_sketches.test_10_the_stream_follows_an_account_switch_in_the_same_tab hung at Sign out. Its diagnostic sketch rerun also reported assistant-runs access-control page errors; they were retained, not filtered.
  • Frozen-main control: detached main 4697fadc077adc39f1ebbce12c9ae46a5a0f74d7, unchanged production code. The only fixture edit was test_sketches.py's launch from cls.pw.chromium.launch() to cls.pw.webkit.launch(). Test 01 passed; test 10 again stalled. The bounded 360-second process exited 124, so this is incomplete/failing evidence, not a passing suite.
  • A separate Home-only WebKit probe on that same baseline never mounted a map. It used a fresh account/context at 1440×900, navigated to Home, opened Account and clicked Sign out with no_wait_after=True, then explicitly waited 10 seconds for **/sign-in*. The click returned; the URL stayed Home; the explicit URL assertion timed out. No /api/auth/sign-out POST reached the API in the observed interval. A subsequent browser query also stalled, and the outer 90-second probe exited 124.
  • Before that click the actual page reported secure=true, PushManager and Notification exposed, no active/waiting worker, and registration.installing.state="installing". This is headless WebKit emulation evidence, not a claim about physical Safari.

Environment: the repository's pinned Playwright Python 1.62.0 Noble image/digest in docker/ui-tests.Dockerfile; Docker/Compose source stack; loopback origin http://127.0.0.1:19800, mail port 19801, blank FLUX_VAPID_PUBLIC_KEY/FLUX_VAPID_PRIVATE_KEY, isolated accounts/volumes. check_ui.sh commands and assertions are unchanged. Automatic Docker pools were exhausted, so a temporary IPAM-only override supplied default 10.198.80.0/24, runtime-control 10.198.81.0/24 and runtime-api 10.198.82.0/24, preserving internal flags. Other environments were untouched.

Local reproducibility artifacts: /tmp/flux-380-baseline-webkit.log, /tmp/flux-380-webkit-signout-probe.py, /tmp/flux-380-webkit-signout-probe.log, /tmp/flux-380-check-ui.sh, /tmp/flux-380-networks.yaml; detached baseline checkout /home/hubert/Develop/flux/.worktrees/map-380-baseline-4697. The original diagnostic logs are /tmp/flux-380-webkit{,-debug}.log. The owned one-off test container was removed after timeout; it had left its network occupied during normal cleanup.

To reproduce the baseline suite, set FLUX_380_CHECKOUT to the detached baseline path and run the trusted script plus the recorded IPAM override with FLUX_UI_BROWSER=webkit, ports 19800/19801, and test names test_sketches.SketchJourney.test_01_start_a_private_sketch_and_add_thoughts test_sketches.SketchJourney.test_10_the_stream_follows_an_account_switch_in_the_same_tab. The Home probe source records every step and retains request/page-error observations; no route/API/browser-error filter was applied.

Hypothesis, not an established cause

signOutDevice() awaits disablePushNotifications() before its POST; that cleanup reads the service-worker registration and native push subscription. An exposed native push API during an unfinished worker install is therefore a candidate wait point. Browser/driver or fixture behavior may also be involved: instrument and distinguish them before changing production or the trusted harness. The Push API standard and WebKit's push description describe the API, not proof of this failure's cause. Do not broadly disable workers/push or discard page errors to obtain a green run.

Acceptance criteria

  • AC-1 — Diagnose: reproduce the Home-only and retained account-switch cases at pinned source/tool versions; identify the actual wait point and distinguish production behavior from browser/fixture limitations. Keep observed failures and hypotheses separate.
  • AC-2 — Complete logout: after the evidence-driven correction, ordinary Sign out reaches its real POST and sign-in result within a documented bounded interval during first install/update waiting and push unavailable/default/denied states. Cover subscribed cleanup through the supported #20 verification path; do not fake successful logout or remove that path.
  • AC-3 — Preserve privacy: server session revocation and deletion of its push subscriptions still occur; browser subscription/cache/draft cleanup remains correct. Sign-in as a second account cannot expose the first account's data or reuse its stream cursor. Keep current access/revocation and generic-preview rules unchanged.
  • AC-4 — Verify: relevant Chromium and WebKit emulation regressions pass on the corrected candidate, including the full retained account-switch scenario and page-error assertions. Document remaining native-emulation limitations honestly and obtain independent current-head review. A screenshot or a filtered/disabled check cannot count as completion.

Handoff and unblock condition

@Zamojski5: please classify the exact pre-POST wait and own its bounded correction under the existing PWA contracts. #380 continues its independent map work; it does not accept whole WebKit authentication/PWA behavior. This blocker clears when AC-1–AC-4 have actual corrected-head evidence and independent review. No production PWA edit has been made in #380.

Lingua principale
TypeScript
Stelle
3
Fork
0
Merge medio
22h 53m
PR unite (30g)
272

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ColdPhase/flux

Tutte le issue di ColdPhase/flux

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.