<div dir="ltr"><div>Hi Mark and Kit!</div><div><br></div>cc dev-fxaccount because there's nothing secret here.<div><br></div><div>It's the middle of the night for Mark, I wouldn't you to have seen this response in IRC.</div><div><br></div><div>Copying Mark's comments from IRC:</div><br>> re <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1357085">bug 1357085</a> [1] - until we do kill about:accounts, can't about:accounts itself just transition to a better a.f.c page instead of a more complex capabilities solution?<br>> (ie, hard-code a new url instead of about:prefs)<div>...<br>> I'm probably missing something subtle, but Kit writes "In both cases, I got stuck at the confirmation screen if I removed the `openPrefs` calls from `aboutaccounts.js`." - and openPrefs is literally |window.location = "about:preferences#sync"| - so I'm thinking |window.location = "<a href="https://accounts.firefox.com/something-better">https://accounts.firefox.com/something-better</a>"|<div><div><br></div><div>Copying in (a heavily modified version of) my response:</div><div><br></div>I'm slightly uncomfortable with that approach because it reduces the flexibility we have on the FxA side to determine the next steps, though I'm mulling over whether we can retain the flexibility. For example, we recently made changes to the signup flow in the firstrun page to encourage users to connect a second device - the UI that is displayed to the user depends in part on the user's country. Users in the US, Canada, and GB can send themselves an SMS, users in other parts of the world cannot. This decision making currently occurs in the /confirm page when verification polling has indicated the user verified their account.<br><br></div><div>If the user can send themselves an SMS, we send them to /sms, if the user is ineligible to send an SMS, we try to send them to /connect_another_device, and if they aren't eligible for /connect_another_device either, we send them to /signup_confirmed. It's a nasty decision tree. We could move that decision tree logic elsewhere, onto an endpoint you could point at, though I suspect we'd need an endpoint for each of signin, signup, and password reset. This seems to just shift the complexity. I suggested the "capability" approach because we already have a "cadAfterSignUpConfirmationPoll" capability internally [2], I was hoping to hook into that because it's pretty dead simple on our end.</div><div><br></div><div>Shane<br><br>[1] - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1357085">https://bugzilla.mozilla.org/show_bug.cgi?id=1357085</a></div></div><div>[2] - <a href="https://github.com/mozilla/fxa-content-server/blob/d22f4cde9c8c9b54938e8f956b00ded1caf77a24/app/scripts/models/auth_brokers/fx-firstrun-v1.js#L30">https://github.com/mozilla/fxa-content-server/blob/d22f4cde9c8c9b54938e8f956b00ded1caf77a24/app/scripts/models/auth_brokers/fx-firstrun-v1.js#L30</a></div></div>