PWA: diagnose and fix WebKit Sign out stalling before the auth POST
Maintainers usually reply within 1 day
Assessment
This issue has not been assessed yet.
Description
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 main4697fadc077adc39f1ebbce12c9ae46a5a0f74d7: Chromium 44 affected tests passed; WebKit map-connect 9 passed, buttest_sketches.test_10_the_stream_follows_an_account_switch_in_the_same_tabhung 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 wastest_sketches.py's launch fromcls.pw.chromium.launch()tocls.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-outPOST 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,PushManagerandNotificationexposed, no active/waiting worker, andregistration.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.
- Dominant language
- TypeScript
- Stars
- 3
- Forks
- 0
- Avg merge
- 14h 40m
- Merged PRs (30d)
- 242
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from ColdPhase/flux
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 1 day
-
F-027 A10 — Connect AI order and labels in Settings (rest of #410)Possibly taken @Zamojski5 claimed this today. Open
ColdPhase/flux#493 · 1 comment · 1 assignee ·
Maintainers usually reply within 1 day
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
homarr-labs/dashboard-icons#2939 ·
Maintainers usually reply within 1 day
-
Agent/category reasoning variants are still checked against the stale model cache in chat.paramsOpenopencode
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
code-yeongyu/oh-my-openagent#10003 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
Actions on ToastsOpen
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
nextcloud-libraries/nextcloud-dialogs#2669 ·
Maintainers usually reply within 1 day