On Thu, Aug 24, 2017 at 3:29 AM, Mark Hammond <[email protected]> wrote:
> 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? We can, but we don't to avoid screen flicker. Currently, once Firefox detects the session has become verified it transitions from about:accounts to about:preferences#sync. We originally had FxA transition from /confirm to /signup_confirmed, but this caused ugly screen flicker - FxA would transition from /confirm to /signup_confirmed, then a second later Firefox would take over and transition to about:preferences#sync. I can't find the original issue, but there is [1]. To avoid the flicker, for both signin and signup, we totally stop the flow and let about:accounts take care of screen updates. As long as about:accounts does any automatic transition once it detects session verification, then any transition we would make would be immediately overridden. > If desktop then *stops* transitioning, won't the right thing magically > happen? > It doesn't, again, because we want to avoid flicker we totally stop the flow as soon as we show the "confirm your email" screen. On the FxA side we don't even know the user has confirmed their email address until the next time the user loads up FxA. > > * 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? > This scenario is what I meant by just shifting around the complexity - this would cause us to have to do a lot of work on the FxA side. As rfk mentions, having a page load like this would definitely cause screen flicker. > > 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 :) > Oh I dunno, capabilities can be very light weight, at their simplest they are just a flag in [2]. It's scenarios like this that capabilities were made for! The name of the capability should be more generic than the one I used on the content server, I targeted a single use case with that name. I could imagine something like "aboutAccountsPostVerificationTransitions": "fxa", on the fxa side we could default to "aboutAccountsPostVerificationTransitions": "firefox". The name and values are a strawman proposal. Shane [1] - https://github.com/mozilla/fxa-content-server/blob/3f54018df8c862cd273979be9db38e8de37a4402/app/scripts/models/auth_brokers/fx-desktop-v1.js#L32:L43 [2] - https://dxr.mozilla.org/mozilla-central/rev/f0abd25e1f4acced652d180c34b7c9eda638deb1/services/fxaccounts/FxAccountsWebChannel.jsm#404
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
