<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Aug 24, 2017 at 3:29 AM, Mark Hammond <span dir="ltr"><<a href="mailto:mhammond@mozilla.com" target="_blank">mhammond@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This leaves me with 2 questions:<br>
<br>
* 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? </blockquote><div><br></div><div>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.</div><div><br></div><div>As long as about:accounts does any automatic transition once it detects session verification, then any transition we would make would be immediately overridden.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If desktop then *stops* transitioning, won't the right thing magically happen?<br></blockquote><div><br></div><div><br></div><div>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.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
* 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?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
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 :)<br></blockquote><div><br></div><div><br></div><div>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. </div><div><br></div><div>Shane</div><div><br></div><div>[1] - <a href="https://github.com/mozilla/fxa-content-server/blob/3f54018df8c862cd273979be9db38e8de37a4402/app/scripts/models/auth_brokers/fx-desktop-v1.js#L32:L43">https://github.com/mozilla/fxa-content-server/blob/3f54018df8c862cd273979be9db38e8de37a4402/app/scripts/models/auth_brokers/fx-desktop-v1.js#L32:L43</a></div><div>[2] - <a href="https://dxr.mozilla.org/mozilla-central/rev/f0abd25e1f4acced652d180c34b7c9eda638deb1/services/fxaccounts/FxAccountsWebChannel.jsm#404">https://dxr.mozilla.org/mozilla-central/rev/f0abd25e1f4acced652d180c34b7c9eda638deb1/services/fxaccounts/FxAccountsWebChannel.jsm#404</a></div></div></div></div>