The peer lobby stays on "Checking account..." when an invite link is opened with site data blocked

オープン
  • 何か問題がありますか？
#626 コメント 3 件 リアクション 0 件 担当者 1 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@dges5202 がすでに取り組んでいます。

2026年11月8日 から。

  • #632 @dges5202 による — オープン

評価

この issue はまだ評価されていません。

説明

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:

  1. 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 shows Uncaught SecurityError: Failed to read the 'sessionStorage' property from 'Window': Access is denied for this document. The address bar still carries #invite=test: the history.replaceState that should drop it, two lines after the sessionStorage.setItem at line 29, never runs.
Image

 

  1. 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 sessionStorage unreachable shows a reason instead of "Checking account...", and a test covers it.
  • The five eslint-disable-next-line directives in web/peer-lobby.js are gone; reportUnusedDisableDirectives makes 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.

主要言語
Rust
スター
223
フォーク
148
平均マージ
1日 4時間
マージ済み PR（30日）
223

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

sysprog21/codetrial のほかの issue

sysprog21/codetrial の issue をすべて見る

似ている issue

Rust の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。