This leaves me with 2 questions:
* In the bug, there was discussion of a capability that indicates "The
browser won't transition to about:preferences#sync afterwards, you take
care of this". Given desktop does this unconditionally, can't you also
transition somewhere unconditionally? If desktop then *stops*
transitioning, won't the right thing magically happen?
* Otherwise, can't we just pick a hard-coded URL that FxA will then
transition from? Eg, if the end-point was, say, "/post-confirmation",
couldn't FxA then redirect from there to, say, /sms if it decided that
was appropriate?
If neither of them work, I'm fine with adding a capability - it's just
that at face value it seems additional complexity for something that
seems like it should be simpler :)
Cheers,
Mark
On 8/24/17 2:48 AM, Shane Tomlinson wrote:
Hi Mark and Kit!
cc dev-fxaccount because there's nothing secret here.
It's the middle of the night for Mark, I wouldn't you to have seen this
response in IRC.
Copying Mark's comments from IRC:
> re bug 1357085
<https://bugzilla.mozilla.org/show_bug.cgi?id=1357085> [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?
> (ie, hard-code a new url instead of about:prefs)
...
> 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 = "https://accounts.firefox.com/something-better";|
Copying in (a heavily modified version of) my response:
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.
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.
Shane
[1] - https://bugzilla.mozilla.org/show_bug.cgi?id=1357085
[2] -
https://github.com/mozilla/fxa-content-server/blob/d22f4cde9c8c9b54938e8f956b00ded1caf77a24/app/scripts/models/auth_brokers/fx-firstrun-v1.js#L30
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
