Repository navigation
The peer lobby stays on "Checking account..." when an invite link is opened with site data blocked #626
Description
Problem
web/peer-lobby.js names the sessionStorage global in five places (lines 29, 187, 253, 262 and 266 at fcae4d8). Where site data is blocked, touching that global throws. #603 fixed the same failure in the lobby and left these five references behind per-line eslint-disable-next-line no-restricted-globals directives, because a mechanical conversion does not fix this page; the maintainer asked for a separate issue in the review of #603.
Current behavior
Reproduced on fcae4d8 in Chromium:
- With the CodeTrial origin added to Chrome's "Not allowed to save data on your device" list (
chrome://settings/content/siteData), open/peer-lobby#invite=test. The page stays on "Checking account...", and the console showsUncaught SecurityError: Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document.The address bar still carries#invite=test: thehistory.replaceStatethat should drop it, two lines after thesessionStorage.setItemat line 29, never runs.
- With site data allowed, the same link moves on: the invite leaves the address bar and the signed-out page goes to
/api/login?next=peer-join(on this local server, without GitHub sign-in configured, that answers a JSON error, which is outside this issue).
Cause
Line 29 runs at module scope: when the URL carries an invite, the page stores the token in sessionStorage and then removes it from the URL. With the global throwing, the module stops there and init() never runs. Lines 187 and 253 run in init() outside any try, so a page that gets past module scope still fails there.
Converting the references to storageArea("sessionStorage") would pass the lint rule but still fail: .setItem and .getItem on the null it returns throw too. The token has to survive the trip to /api/login?next=peer-join and back (line 188), and sessionStorage is the only place the page keeps it.
Desired outcome
With site data blocked, the peer lobby never hangs or shows a raw exception, and it tells the candidate why peer interviews cannot start there.
Open question
Signing in needs the session cookie, which the same block refuses, so a candidate under a full block cannot join a peer interview whatever happens to the token. Is it enough to detect the block (as the lobby does with tabStorageBlocked) and show a site-data message like the lobby's, without trying to keep the token? Or should the token stay in the URL until the join succeeds, for a browser that blocks storage but not cookies?
Acceptance criteria
- Opening an invite link with
sessionStorageunreachable shows a reason instead of "Checking account...", and a test covers it. - The five
eslint-disable-next-linedirectives inweb/peer-lobby.jsare gone;reportUnusedDisableDirectivesmakes each fix remove its own.
Related
#600 and #603 (the same failure in the lobby).
I found this while working on #603 and am not taking it myself; it is open for anyone to pick up.
Activity
dges5202 commentedon Nov 8, 2026
Hi @sidney-Hung — thanks for filing this and leaving it open. I'd like to take it if that works for you.
Plan
Mirror the lobby fix from #603 on the peer-lobby path:
sessionStorageis unreachable (same idea as the lobby'stabStorageBlocked/ safe probe), before any module-scopesessionStoragetouch soinit()can still run.SecurityErrorin the console from those five sites.eslint-disable-next-line no-restricted-globalsdirectives inweb/peer-lobby.jsas each call site is converted; keepreportUnusedDisableDirectiveshappy.Open question (my take)
I'd go with detect the block and show a site-data message, without trying to preserve the invite token across login when storage is blocked.
Reason: a full site-data block also refuses the session cookie, so peer join cannot complete anyway. Keeping the token in the URL until join succeeds adds edge cases (reload / share / history) for a path that still cannot sign in. If maintainers prefer a URL-held token for a hypothetical "storage blocked, cookies allowed" browser, I'm happy to adjust after feedback.
Scope
web/peer-lobby.js(+ shared helper reuse from the lobby fix if one already exists)Please assign this to me if the plan looks right, or tell me what you'd change before I open a PR.
sidney-Hung commentedon Nov 8, 2026
@jserv I opened this as a follow-up and noted I am not taking it myself, and @dges5202 offered to work on it above. Could you assign it to them instead?
jserv commentedon Nov 8, 2026
@dges5202 The plan matches. Detect the block and show the site-data reason; do not try to keep the invite token. A full block refuses the session cookie too, so there is no join to protect, and a browser that blocks storage but allows cookies is its own issue if one turns up.
Run the probe before anything touches
sessionStorageat module scope, usestorageArea("sessionStorage")from #603 (it answers null where the global throws), and remove the fiveeslint-disable-next-linedirectives as each site is converted. The test opens an invite link with storage unreachable and asserts the reason is shown instead of "Checking account...". Open the pull request withCloses #626.Explain site data on a blocked peer invite
Explain site data on a blocked peer invite
Explain site data on a blocked peer invite
Clear the invite hash when site data is blocked
Clear the invite hash when site data is blocked
Explain site data on a blocked peer invite