Fair enough. I'm still not convinced that leaving artifacts around that
say "desktop no longer does some obscure thing it once did" is valuable,
but I'm happy to defer to you here.
Cheers,
Mark
On 8/24/17 6:51 PM, Shane Tomlinson wrote:
On Thu, Aug 24, 2017 at 3:29 AM, Mark Hammond <[email protected]
<mailto:[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
