FxA authentication should not immediately redirect back to Sync prefs

RESOLVED DUPLICATE of bug 1335491

Status

()

Firefox for iOS
Sync
P2
major
Rank:
1
RESOLVED DUPLICATE of bug 1335491
2 years ago
a year ago

People

(Reporter: rfeeley, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
Other
iOS

Firefox Tracking Flags

(fxios6.0+)

Details

(Whiteboard: [MobileCore][fxa-waffle])

Attachments

(3 attachments)

(Reporter)

Description

2 years ago
Created attachment 8774771 [details]
verify.png

Currently when users create a Firefox Account to Sync in iOS, they are immediately returned to the Sync prefs with "Verify your email address" in black type beneath the email.

We will soon be turning on sign-in confirmation for all accounts where all Sync sign-ins with require email verification. We would like to keep everyone alive through this difficult journey. It presents a page much like the Confirm your account screen.

Some improvements:
1. This copy should probably match the colour of the Log out button below.
2. The user should have to manually exit this screen. It should not auto-return.

Updated

2 years ago
Flags: needinfo?

Updated

2 years ago
Flags: needinfo?
tracking-fxios: --- → ?
Sign-in confirmation also breaks the sign in user flow if the user sings in through the last slide of first run. It redirects the user to his homepage (tiles) without mentioning that an additional step is required.
Here is another related bug which is focused on login from History but still related to login confirmation causing a bad user flow: https://bugzilla.mozilla.org/show_bug.cgi?id=1289887

Updated

2 years ago
Priority: -- → P1

Updated

2 years ago
Duplicate of this bug: 1289887
Whiteboard: [MobileAS Backlog]

Updated

2 years ago
Whiteboard: [MobileAS Backlog] → [MobileAS Backlog][fxa-waffle]
Tracking 6.0 in iOS triage.
tracking-fxios: ? → 6.0+
IIUC the next step here, is for someone on the FxA side to summarize in more detail what the problem is and what the solution might look like.  Unfortunately I haven't had the bandwidth to do that and I'm about to head out for a conference - :stomlinson could you please either do that or delegate it?

Of particular interest would be, how Android manages this flow and whether we can get to a similar experience here.
Flags: needinfo?(stomlinson)
Created attachment 8782275 [details]
fennec_signin_confirmation.mov

For comparison, I made a short screencast of the sign-in flow on Fennec, noting how it manages the transition between the various screens.  As a starting point, I think working towards using the same flow on iOS would be valuable.

:rfeeley :st3fan does this seem like something we can aim for from a UX perspective?
Flags: needinfo?(sarentz)
Flags: needinfo?(rfeeley)
Created attachment 8782279 [details]
ios_signin_confirmation.mov

To ensure we're all talking about the same thing, here's a video of the current sign-in flow on iOS.
So AFAICT next steps here are to:

1) Agree on what behaviour we'd like from a UX perspective
2) Come up with an implementation plan and timeline for both Client and Server side
3) Decide if we can add any short-term improvements on the meantime by tweaking things server-side

We've had a few discussions about us being able to change the timing of the "login" message from FxA web content to the browser, but doing so will expose a lot of edge-cases.  I think the right place to fix this is in the client itself.
Flags: needinfo?(stomlinson)
Oh, I meant to ni? Alex on this for input as well...
Flags: needinfo?(adavis)

Updated

2 years ago
Priority: P1 → --

Updated

2 years ago
Whiteboard: [MobileAS Backlog][fxa-waffle] → [MobileAS][fxa-waffle]
Hi Ryan, thanks for providing those recordings. I completely agree. Ideally we get the two user flows to be as similar as possible.

The main thing I see that needs resolving is the redirect to Settings. If we can have that FxA confirmation page to stay put, users will see the message and will solve the problem. There is already a back button at the top already so they can easily navigate back to setting once their email is verified.

As per the best way to achieve this, I will let engineering figure out if it's client or server side.

As a reminder, we observe the same behavior when users login via History and during First Run. If we prevent the automatic redirect, we should resolve the user flow everywhere so long as there always a button at the bottom of the confirmation page to close the dialog or move to the next step/page.

rfeeley: can you identify if (and what) buttons should go at the bottom of the confirmation message after login?
Flags: needinfo?(adavis)
I count three ways to get to the FxA sign-in screen on iOS:

* From the last slide of the first-run experience
* On the "history" view, selecting "Synced devices" then "Sign in to Firefox"
* By manually navigating in through settings and choosing "Sign in to Firefox"

Stephan, are there any others we should be aware of?
Flags: needinfo?(sarentz) → needinfo?(sleroux)
Nope that should be all the ways.
Flags: needinfo?(sleroux)
A phased approach will probably work best to "fix" the problem of iOS taking control of the UI immediately w/o the user seeing the "Confirm your email" screen.

FxA based nomenclature:
authentication broker - a construct that acts as environment specific configuration/state manager. There are distinct auth brokers for e.g., Desktop firstrun, Desktop "about:accounts", Fx for iOS, and Fx for Android because each of these flows are slightly different.
CWTS (Choose What To Sync) - CWTS is UI that allows a user to select which types of data to be synced.

Phase 1) The content server delays sending the `login` message for an short amount of time, perhaps 5-7 seconds. This will give users enough time to read the "Go confirm your email" message, but (hopefully) not enough time to close the window or browse away before the `login` message is sent. If the `login` message is not sent before the user browses away, then Fx for iOS will never know the user is signing up/in. We might be able to mitigate this with some clever use of the `beforeunload` DOM event handler. This change will only affect the "fx_ios_v1" authentication broker. This can be rolled out within a couple of weeks. This will *not* affect the already existing but unused "fx_ios_v2" authentication broker. See "*" below.

Phase 2) The iOS client stops taking over the UI upon receiving the `login` message and updates the `context` query parameter used to open FxA from "fx_ios_v1" to "fx_ios_v2". iOS will instead continue to display the FxA window, start its internal state machine, and wait for verification. The "back" button will continue to be available in the FxA container window, a user that clicks this button will be taken to the previous screen. If it's the settings screen, the existing "verify your email" message will be displayed. If another screen, it's state should be updated to reflect the fact that the user must verify their email.

* - an `fx_ios_v2` authentication broker already exists [1] that enables CWTS and uses WebChannels instead of CustomEvents to communicate. The corresponding change to Fx for iOS was never written and the `fx_ios_v1` auth broker is still being used. :rfkelly today noticed that on signup, the user has no ability to select which data types to sync. Neither FxA nor Fx for iOS present UI. This is a separate issue that we should resolve.

Since the fx_ios_v2 auth broker is not currently being used, we could re-purpose it to act exactly like the fx_ios_v1 auth broker, except it will not contain the delay.


[1] - https://github.com/mozilla/fxa-content-server/blob/master/app/scripts/models/auth_brokers/fx-ios-v2.js

Updated

2 years ago
Priority: -- → P3
Sounds like a good plan, and I think we should try to do the phase-1 part ASAP.  I filed a bug for it here: https://github.com/mozilla/fxa-content-server/issues/4077
We've completed Phase 1 of Comment 13, and it will go live with the next deploy of FxA.

I think we should still try to get Phase 2 done, bringing the flow here into closer alignment with the flow on Android.  But this will require non-trivial amounts of client-side dev work so most likely it will need to wait for prioritization on Fx-iOS dev side.
Rank: 1
Duplicate of this bug: 1303832
Severity: normal → major
Priority: P3 → P2
See Also: → bug 1311690
From Comment 13

> If the `login` message is not sent before the user browses away, then Fx for iOS will never know the user is signing up/in. We might be able to mitigate this with some clever use of the `beforeunload` DOM event handler. This change will only affect the "fx_ios_v1" authentication broker.

This seems like the cause of https://bugzilla.mozilla.org/show_bug.cgi?id=1311690. I wouldn't be surprised if this happens somewhat frequently for users and when it does it has the consequence of forgetting the users account. This in turn would force them to re-enter their credentials which just adds more barrier to getting sign ups.

> We might be able to mitigate this with some clever use of the `beforeunload` DOM event handler. This change will only affect the "fx_ios_v1" authentication broker.

I'm assuming from the behavior this isn't in place today. Is this solution or something similar possible to implement in the interim until we can rejig the user flow to handle Phase 2?
Flags: needinfo?(stomlinson)
Clearing ni? :rfeeley since I don't think the question I asked him is particularly relevant anymore
Flags: needinfo?(rfeeley)
(In reply to Stephan Leroux [:sleroux] from comment #17)
> From Comment 13
> 
> > If the `login` message is not sent before the user browses away, then Fx for iOS will never know the user is signing up/in. We might be able to mitigate this with some clever use of the `beforeunload` DOM event handler. This change will only affect the "fx_ios_v1" authentication broker.
> 
> This seems like the cause of
> https://bugzilla.mozilla.org/show_bug.cgi?id=1311690. I wouldn't be
> surprised if this happens somewhat frequently for users and when it does it
> has the consequence of forgetting the users account. This in turn would
> force them to re-enter their credentials which just adds more barrier to
> getting sign ups.
> 
> > We might be able to mitigate this with some clever use of the `beforeunload` DOM event handler. This change will only affect the "fx_ios_v1" authentication broker.
> 
> I'm assuming from the behavior this isn't in place today. Is this solution
> or something similar possible to implement in the interim until we can rejig
> the user flow to handle Phase 2?


Correct, this behavior is not in place today unless somebody did it while I wasn't looking. I just opened [1] to try using a beforeunload handler to send the `login` message. Thanks for reminding us Steph!

[1] - https://github.com/mozilla/fxa-content-server/issues/4377
Flags: needinfo?(stomlinson)
Iteration: --- → 1.9
Iteration: 1.9 → 1.10
Whiteboard: [MobileAS][fxa-waffle] → [MobileCore][fxa-waffle]
One idea we have in triage was if we could do something on the client side to prevent the delayed redirect back to settings. Unfortunately, since signing into FxA remembers if you've previously confirmed a device, we won't always be shown the 'Confirm Email' screen so by disabling the redirect code, the user will stay stuck on the loading FxA screen after signing into a device they have signed into before.
> the user will stay stuck on the loading FxA screen after signing into a device
> they have signed into before.

Would it help if FxA showed a more appropriate screen in this case?
Blocks: 1337406
Sorry, I was unaware of this bug. The work was done in bug 1335491 so I will mark this one as a dupe.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1335491
You need to log in before you can comment on or make changes to this bug.