1508313 - Sign in validation

Status: NEW

(Firefox for iOS :: General, defect)

Description

[n.acevedos]

Attachment: ScreenRecording_11-19-2018 10-48-53.MP4

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_1) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.1 Safari/605.1.15

Steps to reproduce:

Tried to create a Firefox account with a large and invalid email.


Actual results:

Firefox confirmed the account was successfully created and then returned to the create account view with an error saying that the verification email was returned. 


Expected results:

There should not be a confirmation of successful account creation if the email is not a valid one.

Comment 1

[Justin D'Arcangelo [:justindarc]]

Eduard, any ideas what's going on here?

Comment 2

[Edouard Oger [:eoger]]

Pinging content people

Comment 3

[Shane Tomlinson [:stomlinson]]

There are several levels of "validation" going on:

1. At the content server (web front end), which allows email addresses from IETF spec 5321 [1]. An email address may be up to 256 characters long.
2. At the auth server, which is slightly less restrictive, allowing unicode characters.
3. On Amazon when sending the email.
4. On Amazon if the email is bounced for not being a routable domain.
5. On Amazon if the email is bounced for not being a routable username on a valid domain.

There are a large class of addresses that are considered valid but are not routable. From the image, it looks like the user hit stage 5. Because an email address can be up to 256 characters long, the one the user entered is "valid" but not routable. There's no way for us to know the email doesn't exist on the target domain's email provider until they send a bounce notification.

[1] - https://tools.ietf.org/html/rfc5321#section-4.5.3.1

Comment 4

[n.acevedos]

Thanks for the info. I understand, but the app should not notify the user the successful confirmation, there should be an activity indicator or a progress bar to inform the user a validation is in course, until the final response is received by the app. No matter the level of validation, the response to the user should be consistent at all times. 

Besides that, in the worst case scenario if the user taps the "save settings" button when the successful confirmation appears, the error message is not even shown when it takes the user back to the login window.

Comment 5

[Shane Tomlinson [:stomlinson]]

(In reply to n.acevedos from comment #4)
> Thanks for the info. I understand, but the app should not notify the user
> the successful confirmation, there should be an activity indicator or a
> progress bar to inform the user a validation is in course, until the final
> response is received by the app. No matter the level of validation, the
> response to the user should be consistent at all times. 

Thanks for taking the time to file this bug and respond. Is there any way you could 
capture a video of your experience? I believe we are talking about the same flow but 
want to make sure.

Some background, knowledge of the constraints might help generate additional suggestions.

We looked at the suggested approach early on, but because email sending is asynchronous,
tried to make affordances so users do not think Firefox Accounts is broken and reload 
the page.

Once we send an email, we do not know whether the email provider will accept the message 
immediately. Sometimes it's accepted, sometimes it bounces, in both cases we only
know that several seconds to several minutes after sending the email. Last I looked, the
mean time was around 5 seconds to receive a response. For emails that are only responded
to after several minutes, showing a spinner for that entire time would cause the majority 
of users would think Firefox Accounts was in a stalled state and either reload or leave
the page. Both actions would cause a high-level of user drop-off.

Compared to the volume of emails that are successfully sent, bounces are relatively infrequent. 
Optimizing for the failure mode would cause a poor experience for the far greater number of users 
whose emails are successfully sent. Instead, we optimistically show an "Account created, 
go confirm your email" screen, because this is true, an account *is* created, one in an 
unverified state. We then wait for one of 2 possible signals to transition:

1) Account verification
2) Bounce notification 

An email bounce causes the account to be deleted. Account verification causes the account to be 
changed to the "verified" state.