<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 24 August 2017 at 12:29, 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:0 0 0 .8ex;border-left:1px #ccc solid;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? If desktop then *stops* transitioning, won't the right thing magically happen?<br></blockquote><div><br></div><div>IIRC this can sometimes lead to an unpleasant "flicker" effect, where the user sees the page begin to transition to something else briefly before the browser navigates it to about:preferences#sync. I guess we could try it out and see how it behaves in practice.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* 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><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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>
<br></blockquote><div><br></div><div>If we do end up adding a capability, perhaps it should be something more broad than just "I will not make this specific transition". Would it make sense for the browser to signal "I'm not going to make any page transitions myself, you'll need to device what content to show at each point" and then just let FxA web content drive in all cases?<br></div><div> </div><div><br></div><div> Ryan</div><div><br></div><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 8/24/17 2:48 AM, Shane Tomlinson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Mark and Kit!<br>
<br>
cc dev-fxaccount because there's nothing secret here.<br>
<br>
It's the middle of the night for Mark, I wouldn't you to have seen this response in IRC.<br>
<br>
Copying Mark's comments from IRC:<br>
<br>
> re bug 1357085 <<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1357085" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=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)<br>
...<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" rel="noreferrer" target="_blank">https://accounts.firefox.com/<wbr>something-better</a>"|<br>
<br>
Copying in (a heavily modified version of) my response:<br>
<br>
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>
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 "cadAfterSignUpConfirmationPol<wbr>l" capability internally [2], I was hoping to hook into that because it's pretty dead simple on our end.<br>
<br>
Shane<br>
<br>
[1] - <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1357085" rel="noreferrer" target="_blank">https://bugzilla.mozilla.org/s<wbr>how_bug.cgi?id=1357085</a><br>
[2] - <a href="https://github.com/mozilla/fxa-content-server/blob/d22f4cde9c8c9b54938e8f956b00ded1caf77a24/app/scripts/models/auth_brokers/fx-firstrun-v1.js#L30" rel="noreferrer" target="_blank">https://github.com/mozilla/fxa<wbr>-content-server/blob/d22f4cde9<wbr>c8c9b54938e8f956b00ded1caf77a2<wbr>4/app/scripts/models/auth_<wbr>brokers/fx-firstrun-v1.js#L30</a><br>
</blockquote>
<br>
______________________________<wbr>_________________<br>
Dev-fxacct mailing list<br>
<a href="mailto:Dev-fxacct@mozilla.org" target="_blank">Dev-fxacct@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/dev-fxacct" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/dev-fxacct</a><br>
</blockquote></div><br></div></div>