Skip to content

fix(background): treat about:blank as an unsettled tab url in the attach probe - #1530

Merged
Comp0te merged 1 commit into
developfrom
WALLET-1439-firefox-sign-popup-stuck
Aug 31, 2026
Merged

fix(background): treat about:blank as an unsettled tab url in the attach probe#1530
Comp0te merged 1 commit into
developfrom
WALLET-1439-firefox-sign-popup-stuck

Conversation

@Comp0te

@Comp0te Comp0te commented Aug 31, 2026

Copy link
Copy Markdown
Collaborator

Description

On Firefox the sign approval window opens but never renders the request — the page sits on its skeleton and the dapp waits forever (WALLET-1439). Chrome is unaffected.

The cause is the attach-time ownership probe in attachWindowToRequest. Once windows.create resolves, the probe reads the new window's first tab and repairs the attach — i.e. cancels the request — when the tab's URL provably is not an extension page. In front of that sits a guard whose whole job is to let inconclusive shapes pass untouched, because repairing on one cancels an approval that is on screen. That guard only knew Chrome's unsettled shape: a navigating tab reported as url: '' with the real target in pendingUrl.

Firefox has no pendingUrl at all, and reports a freshly created window's tab as about:blank until the navigation commits. On a cold popup load that commit loses the race with the probe, so about:blank fell through to !tabUrl.startsWith(runtime.getURL('')), the wallet's own window was read as foreign, and the request it was about to display was cancelled. Cancelling deletes the stored signing payload — so the popup already on screen had nothing left to render, which is the stuck skeleton in the report.

What changed

  • about:blank joins null and '' as an unsettled tab URL in the probe's guard, and the comment there now enumerates the shapes per browser instead of describing Chrome's as if it were universal.
  • A regression test for the Firefox shape ({ tabs: [{ url: 'about:blank' }] }) asserting the probe does not cancel.

This only widens the inconclusive set, not the accept set — the file's existing asymmetry (a provable verdict repairs, anything inconclusive does not) is what makes that safe. Detection is not weakened: a window that genuinely is not ours settles on a non-extension URL, and the foreign-window case that this arm exists for is still caught. about:blank was never a verdict in the first place; it was being treated as one.

Verification

  • npm run ci-check — format:check, lint, tsc, knip and the full jest suite with coverage, all green (run by the pre-push hook).
  • No UI verification: the change is background-only, and the symptom reproduces on Firefox, which the extension's agent-browser harness does not drive — the Chrome path this fix does not touch is the one it could exercise.

Linked tickets

WALLET-1439

Checklist

  • Make sure this PR title follows semantic release conventions: https://semantic-release.gitbook.io/semantic-release/#commit-message-format

  • If the PR adds any new text to the UI, make sure they are localized — no UI text added

  • Include a screenshot or recording if implementing significant UI or user flow change — background-only, no UI change

  • When this PR affects architecture changes wait for review from Dmytro before merging

…ach probe

On Firefox a freshly created approval window's tab reports about:blank
until the navigation commits (there is no pendingUrl there), so the
attach-time ownership probe raced the popup's cold load, read the window
as foreign and cancelled the request it was about to display — deleting
the signing payload and leaving the page on its skeleton (WALLET-1439).
Chrome was unaffected: it reports the same gap as url '' plus pendingUrl,
which the guard already covered.
@Comp0te Comp0te self-assigned this Aug 31, 2026
@Comp0te Comp0te added the bug Something isn't working label Aug 31, 2026
@Comp0te
Comp0te merged commit c7ba4ee into develop Aug 31, 2026
7 checks passed
@Comp0te
Comp0te deleted the WALLET-1439-firefox-sign-popup-stuck branch August 31, 2026 13:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant