Use the session-verification-poll-mixin in the CWTS page to
handle both bounces and auto-submit the form if verification completes.
fixes#4094fixes#4193
Extract the logic to do the signup/signin verification polling
from models/account.js into its own model, models/polls/session.js
Extract most of the polling logic from /confirm into
its own mixin, session-verification-poll-mixin. This
will allow the common logic to be used on CWTS.
The poll is started when entering the /confirm page,
stopped when leaving.
The hope is that this will make #4094 and #4193 very easy.
fixes#5323fixes#5325
Instead of using a nth-child selector in the tests, give the
email-suggestion element an ID that can be checked for and
clicked. Hopefully this is a bit more sane.
Tangential changes:
* Modify the styles slightly to not use a `> span`, and instead
use classes and IDs. > span is slow because of CSS pattern matches
operate from right to left.
fixes#5309
The email first flow is available for Sync if the action=email query parameter is specified. The opt-in allows us to release and test without interfering w/ other views & flows. If action=email is not specified and no user is signed in, users should be sent to /signup. If a user is signed in, action is ignored, the user will be sent to /settings.
On the / screen, if the user enters an email that is registered, they will be sent to /signin. If the email isn't registered, they'll be sent to /signup. Note, an email that is registered but has not yet verified will be sent to /signin. The user can reset their password if they really want to re-register.
Once a user is on /signin or /signup, if the user decides they want to change their email, they'll be sent back to / to edit their email. This avoids having to deal with things like signin-from-signup or handling Account doesn't exist errors on the signin page.
I opted to use totally new views instead of the existing SignInView and SignUpView for a couple of reasons. First, this is an experiment. If the experiment fails, I want to be able to easily remove the code. Second, if the experiment succeeds, I want to be able to rip out the old views. There is so much complexity to handle corner cases that'll be avoided with this flow.
If the experiment succeeds, we'll need to update the new signin view to handle OAuth flows and the user's avatar, but that's in the future.
Note, I did not add an A/B test or metrics for this. That'll be a follow on PR, this portion is already large enough.
Note for testing: open https://127.0.0.1:3030/?service=sync&context=fx_firstrun_v2&action=emailfixes#5194
The new officially supported way to enable signinCodes is to use:
`&forceExperiment=sendSms&forceExperimentGroup=signinCodes`
Support for `&signinCodes=true` has been removed.
After adding the ExperimentMixin to the SmsMixin, I saw a bug
in the ExperimentMixin where it assumes `this._account` always
exists on the View, which isn't the case for the SMSSendView.
Most views declare a `this.getAccount()` function that returns
the account being used. I updated the mixin to first check for
`this.getAccount`, then as a fallback, use `this._account`
fixes#5278
The tests that deselected a bucket on CWTS failed on Fx 54
because the original input element is too small to click
after being updated to use the Google Material style.
The fixes the problem by moving the label used as the selector
from the input element to the label, which is always visible.
fixes#5330
The experiment mixin made an assumption that `this.experiments` was always
available in the delegate methods. This assumption is invalid once view.destroy
is called.
This caused a problem on the confirm page - if the app was polling for
an email confirmation and the user clicks the browser's `back` button,
the confirm view was destroyed when the page went back to CWTS, but
the poll continued. If the user verified their email, the poll would
complete, which would then attempt to call the confirm view's
`isInExperimentGroup` function. Since the view was destroyed,
`view.experiments` was `null`. Kaboom.
issue #5323fixes#5324
The reset_password view hard coded it's previous view,
which makes it more difficult to use reset_password
from other views than needs to be.
Use the back-mixin which provides generic functionality.
There was a timing problem - after clicking the logout link,
the test did not wait for the logout action to complete before
attempting to reload the page. 123done would cause a browser
modal dialog to display, which caused the test to fail.
fixes#5307
There were a couple of timing problems when run against latest.
* When the SIGNOUT button was clicked, the tests did not wait
for the action to complete before navigating to the next page.
* The reset password test opened a new tab and didn't close it.
fixes#5304
* fix(back): Clicks on the hash button no longer append # to the URL.
`preventDefaultThen` was being called in the wrong place. We were not
calling it on click handlers, but we were always calling it on keyup,
event if the key was not `ENTER`.
fixes#5290
* fix(test): Test to ensure event.preventDefault is called on #back.
The OAuth handshake tests hard coded a test client_id that is valid
against the local server. The same client_id is not valid against
latest/stage/prod.
To get a real client_id, go to an actual 123done instance, then
redirect to the content server and continue the tests.
Note, these tests were extracted from fx_desktop_handshake
into oauth_handshake because OAuth tests cannot be run on circle
since circle doesn't have access to an OAuth relier.
The test is added to the OAuth list, which *is* run when running
the full list. TeamCity uses the full list, so the test will
be run there.
fixes#5300
After requesting account data from the browser it is written
to storage inside of a promise. We were not waiting for the
promise to complete before starting the complete_sign_up
view, which checks storage for the account data that is not
yet written. No account is returned, so a new account is
created with the data present in the verification link,
which does not include a sessionToken. When the SMS check
occurs, the account has no sessionToken, so we force
the user down the CAD flow.
The fix? Add a `return` so the promise is propagated
whenever user.setSignedInAccountFromBrowserAccountData is
called.
fixes#5285
The OAuth handshake tests hard coded a test client_id that is valid
against the local server. The same client_id is not valid against
latest/stage/prod.
To get a real client_id, go to an actual 123done instance, then
redirect to the content server and continue the tests.
Note, these tests were extracted from fx_desktop_handshake
into oauth_handshake because OAuth tests cannot be run on circle
since circle doesn't have access to an OAuth relier.
The test is added to the OAuth list, which *is* run when running
the full list. TeamCity uses the full list, so the test will
be run there.
fixes#5300
What is the problem?
When going "back" through history, the router creates a new model
for the previous view. This causes problems in email-first where
the user's email address on /signup_password is filled in from
an `account` model. Users that go to the TOS/PP agreements then
click "back" are sent all the way back to `/email` because a new
view is created for /signup_password.
How does this fix the problem?
Keep a stack of viewModels. When going back through history,
re-use the same model that was used the first time a view is
displayed.
extraction from #5177
COPPA was originally extracted from the signup flow into its own
view because we had two variations to A/B test. This variant won.
I want to re-use the COPPA logic in the email-first flow. Initially
a mixin was created that creates the COPPA logic. The mixin ended
up doing a lot of plumbing between the consuming object and the
COPPA object, things like delegating to COPPA object methods, event
delegation from the COPPA object to the consuming object, etc.
This housekeeping seemed unnecessary with mixins. Instead
of pushing all responsibilities to the COPPA object, the consuming
object takes over these responsibilities via the mixin.
Extraction from #5177