Skip to content

fix(settings): query fxaStatus on pairing entry pages even for web integrations - #21190

Merged
dschom merged 1 commit into
mainfrom
FXA-14500
Sep 17, 2026
Merged

dschom merged 1 commit into
mainfrom
FXA-14500

Conversation

@dschom

@dschom dschom commented Sep 11, 2026 •

Copy link
Copy Markdown
Contributor

Because

  • A plain /pair or /connect_another_device URL with no context builds a
    Web integration, so useFxAStatus never asked the browser.
  • Without the browser's pairingVersion, the page guessed and sent v2
    browsers down the v1 pairing flow.

This pull request

  • Adds isPairingEntryPathname and treats matching routes as pairing
    flows in useFxAStatus.
  • Passes location.pathname into useFxAStatus from
    AuthAndAccountSetupRoutes.
  • Adds tests for the Web integration pairing entry case and the
    pathname matcher.

Issue that this pull request solves

Closes: FXA-14500

Checklist

Put an x in the boxes that apply

  • My commit is GPG signed.
  • If applicable, I have modified or added tests which pass locally.
  • I have added necessary documentation (if appropriate).
  • I have verified that my changes render correctly in RTL (if appropriate).
  • I have manually reviewed all AI generated code.

How to review (Optional)

Pretty easy to review. Just make sure v2 pairing is supported in fxa and desktop, and then go to http://localhost:3030/pair. Before these changes we'd have seen the interstitial, now we see the V2 pairing code.

Screenshots (Optional)

FXA-14500 — direct /pair on Firefox Nightly with identity.fxaccounts.pairing.version = 2

Stack serving pairing.version = 2, signed-in Nightly, plain /pair with no query string.

Before (main) After (this branch)
Before: v1 choice screen on /pair After: v2 QR rendered on /pair/authority/scan_qr

On main the page never asks the browser for fxa_status, defaults to pairing v1, and shows the choice screen. On this branch it negotiates into /pair/authority/scan_qr (no v=2 in the URL) and the QR renders.

Other information (Optional)

…tions

Because:

- A plain /pair or /connect_another_device URL with no context builds a
  Web integration, so useFxAStatus never asked the browser.
- Without the browser's pairingVersion, the page guessed and sent v2
  browsers down the v1 pairing flow.

This commit:

- Adds isPairingEntryPathname and treats matching routes as pairing
  flows in useFxAStatus.
- Passes location.pathname into useFxAStatus from
  AuthAndAccountSetupRoutes.
- Adds tests for the Web integration pairing entry case and the
  pathname matcher.
@dschom dschom changed the title test(functional-tests): cover the /pair/ trailing-slash entry fix(settings): query fxaStatus on pairing entry pages even for web integrations Sep 16, 2026
@dschom
dschom marked this pull request as ready for review September 16, 2026 18:48
@dschom
dschom requested a review from a team as a code owner September 16, 2026 18:48

@LZoog LZoog left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense.

@dschom
dschom merged commit 5452d71 into main Sep 17, 2026
21 checks passed
@dschom
dschom deleted the FXA-14500 branch September 17, 2026 21:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants