feat(client): Initial Fennec integration work - the new *_complete screens. #3094
Conversation
Just to ensure situation awareness: are we planning to depend on some minimal capabilities stuff for this integration? I got the impression we were taking that out of the critical path. |
I am fleshing out how the internal API would look, where something akin to capabilities are still useful for determining whether things like the "open preferences" button is supported. @ncalexan, @vladikoff and I are going to talk about the external/relier API on Thursday after the fxa-web meeting to see if it's necessary for v1. @vladikoff thinks yes. I don't have enough context yet and want more info. |
Ref #3077 |
| } | ||
| }), | ||
|
|
||
| notifyOfSyncPreferences: function () { |
shane-tomlinson
Sep 23, 2015
Author
Member
Change this to openSyncPreferences and document it. Add a stub to the BaseAuthenticationBroker too.
Change this to openSyncPreferences and document it. Add a stub to the BaseAuthenticationBroker too.
06849c4
to
71d24e7
|
This PR breaks the "oauth force_auth with a registered force_email - allows the user to sign in" functional test, not quite ready. |
eb88785
to
fc87fcc
| * Should the *_complete pages show a `Sync preferences` button | ||
| * if the relier is Firefox Sync? | ||
| */ | ||
| syncPreferencesNotification: false |
vladikoff
Oct 1, 2015
Contributor
👍
| {{/isSignIn}} | ||
| {{#isSignUp}} | ||
| <h1 id="fxa-sign-up-complete-header">{{#t}}Account verified{{/t}}</h1> | ||
| {{/isSignUp}} |
vladikoff
Oct 1, 2015
Contributor
nit: we might consider moving this out of here into JS logic and just outputting the correct title, the template is looking a little insane.
nit: we might consider moving this out of here into JS logic and just outputting the correct title, the template is looking a little insane.
shane-tomlinson
Oct 2, 2015
Author
Member
What I really want to do, and the initial approach I used, is to create distinct templates for all of these things, then choose the correct template depending on the type passed in to initialize. This resulted in 5 nearly identical templates. Template partials would reduce the boilerplate, but we haven't gotten that working with compiled Mustache templates.
What I really want to do, and the initial approach I used, is to create distinct templates for all of these things, then choose the correct template depending on the type passed in to initialize. This resulted in 5 nearly identical templates. Template partials would reduce the boilerplate, but we haven't gotten that working with compiled Mustache templates.
shane-tomlinson
Oct 2, 2015
Author
Member
Still, maybe that's the correct way to go, because you are right, this is insanity.
Still, maybe that's the correct way to go, because you are right, this is insanity.
| {{/isSignIn}} | ||
| {{#isSignUp}} | ||
| <p class="account-ready-service">{{#t}}You are now ready to use %(serviceName)s{{/t}}</p> | ||
| {{/isSignUp}} |
vladikoff
Oct 1, 2015
Contributor
same as https://github.com/mozilla/fxa-content-server/pull/3094/files#r40962304
we should file an issue if you agree
same as https://github.com/mozilla/fxa-content-server/pull/3094/files#r40962304
we should file an issue if you agree
| @@ -97,7 +119,7 @@ function (Cocktail, FormView, Template, Url, Constants, ServiceMixin, | |||
| type: this.type | |||
| }; | |||
|
|
|||
| // spring campaign scheduled to launch 6/2 | |||
| var marketingSnippet; | |||
| if (this._able.choose('springCampaign2015')) { | |||
| marketingSnippet = new MarketingSnippetiOS(marketingSnippetOpts); | |||
vladikoff
Oct 1, 2015
Contributor
side-note: I guess we will need to update this very soon, whenever iOS gets shipped in U.S. 🇺🇸
side-note: I guess we will need to update this very soon, whenever iOS gets shipped in U.S.
|
Needs rebase |
| @@ -129,6 +129,7 @@ function ( | |||
| 'confirm_reset_password(/)': showView(ConfirmResetPasswordView), | |||
| 'cookies_disabled(/)': showView(CookiesDisabledView), | |||
| 'force_auth(/)': showView(ForceAuthView), | |||
| 'force_auth_complete(/)': showView(ReadyView, { type: 'force_auth' }), | |||
vladikoff
Oct 1, 2015
Contributor
this view shows "Your account is ready!" no matter what (with or without existing sessions)
Do we need do any checking / error reporting or is that by design?
this view shows "Your account is ready!" no matter what (with or without existing sessions)
Do we need do any checking / error reporting or is that by design?
shane-tomlinson
Oct 2, 2015
Author
Member
Not by design. A well caught overlook.
account_unlock_complete, force_auth_complete, reset_password_complete and signin_complete can all check the user's status since the user should have a sessionToken (or so we say at this point in time). signup_complete may not have a sessionToken if the user verifies in a second browser - the 1st browser shows signup_complete after confirm but has no sessionToken while the second browser receives the sessionToken.
Not by design. A well caught overlook.
account_unlock_complete, force_auth_complete, reset_password_complete and signin_complete can all check the user's status since the user should have a sessionToken (or so we say at this point in time). signup_complete may not have a sessionToken if the user verifies in a second browser - the 1st browser shows signup_complete after confirm but has no sessionToken while the second browser receives the sessionToken.
vladikoff
Oct 5, 2015
Contributor
Ok we should open an issue if needed for throwing on no-session access to http://localhost:3030/force_auth_complete
Ok we should open an issue if needed for throwing on no-session access to http://localhost:3030/force_auth_complete
fdc9e03
to
e7b1ab6
|
|
||
| /*eslint-disable camelcase*/ | ||
|
|
||
| // The "header" and "ready to sync" messages are generated |
shane-tomlinson
Oct 2, 2015
Author
Member
@vladikoff - is this any better? The template is definitely cleaner, but now the JS is smelly.
Other alternatives:
- One template per screen - pro - fewer switches per screen. con w/o native template support for
layout, lots of duplicate HTML across templates. My attempt at a homegrown layout solution was ugly.
- One module per screen with the header HTML and ready to sync text as properties of the module. Pro - each module is relatively clean. Con - explosion of modules to take care of strings.
- Pass the strings in from router.js as configuration. Pro - ready.js is clean. Con - router.js starts to become dirty.
Thoughts?
@vladikoff - is this any better? The template is definitely cleaner, but now the JS is smelly.
Other alternatives:
- One template per screen - pro - fewer switches per screen. con w/o native template support for
layout, lots of duplicate HTML across templates. My attempt at a homegrownlayoutsolution was ugly. - One module per screen with the header HTML and ready to sync text as properties of the module. Pro - each module is relatively clean. Con - explosion of modules to take care of strings.
- Pass the strings in from router.js as configuration. Pro - ready.js is clean. Con - router.js starts to become dirty.
Thoughts?
vladikoff
Oct 2, 2015
Contributor
See note: https://github.com/mozilla/fxa-content-server/pull/3094/files#r41073115
One template per screen -
I like less HTML
One module per screen
this might work if we can extend "ready" properly
Pass the strings in from router.js
Not sold on doing that, seems like if we add a bit more it won't scale.
The current approach should be okay for now, just not a fan of generating that html in the JS file (per my comment)
See note: https://github.com/mozilla/fxa-content-server/pull/3094/files#r41073115
One template per screen -
I like less HTML
One module per screen
this might work if we can extend "ready" properly
Pass the strings in from router.js
Not sold on doing that, seems like if we add a bit more it won't scale.
The current approach should be okay for now, just not a fan of generating that html in the JS file (per my comment)
| {{#accountUnlock}} | ||
| <h1 id="fxa-account-unlock-complete-header">{{#t}}Account unlocked{{/t}}</h1> | ||
| {{/accountUnlock}} | ||
| {{{headerHTML}}} |
vladikoff
Oct 2, 2015
Contributor
@shane-tomlinson generating that html header looks strange, can we change
{{{headerHTML}}} to
<h1 id="{{headerId}}">{{headerTitle}}</h1>
@shane-tomlinson generating that html header looks strange, can we change
{{{headerHTML}}} to
<h1 id="{{headerId}}">{{headerTitle}}</h1>
shane-tomlinson
Oct 5, 2015
Author
Member
I like this solution, it's a good middle ground. 👏
I like this solution, it's a good middle ground.
8d5925b
to
449d0fa
* Hook up support for the signin_complete and force_auth_complete screens. * Disable support for the signup marketing material. * Add a "Sync preferences" button to the *_complete screens. issue #2771
|
@vladikoff - updated w/ your suggestion, thanks! |
feat(client): Initial Fennec integration work - the new *_complete screens. r=vladikoff
issue #2771