On 24 August 2017 at 12:29, 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? If desktop then *stops* > transitioning, won't the right thing magically happen? > 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. > * 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 :) > > 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? Ryan 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/d22f4cde9 >> c8c9b54938e8f956b00ded1caf77a24/app/scripts/models/auth_ >> brokers/fx-firstrun-v1.js#L30 >> > > _______________________________________________ > Dev-fxacct mailing list > [email protected] > https://mail.mozilla.org/listinfo/dev-fxacct >
_______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
