First-run flow fails to sign me in to sync when using an existing account

RESOLVED FIXED

Status

www.mozilla.org
Pages & Content
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: rfkelly, Assigned: jpetto)

Tracking

Production

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kb=1787585])

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
STR:

  * Launch a fresh profile in Fx 38.0.5
  * The first-run flow starts, loading https://www.mozilla.org/en-GB/firefox/38.0.5/firstrun/
  * Click the "Already have one? Sign in." link to sign in to sync with an existing account
  * Sign in with an existing account

Expected result:

  * The browser should be signed in to sync

Actual result:

  * The signin succeeds, but sync is not connected.


AFAICT, the "create a firefox account" link goes to the special "about:accounts" page from which a sync signin can be successfully executed.  The "already have one" link just goes to accounts.firefox.com, so it signs you in to FxA on the web but does not connect sync.

It should somehow land on "about:accounts?action=signin&entrypoint=uitour", which provides the expected experience if I access it directly.

I know we've got much better UI for this coming, e.g. Bug 998051 and friends.  But I think we should either fix or remove the current behaviour in the meantime, depending on what's easier.  It's a pretty confusing/surprising experience.
The UITour API can only trigger the following URL:

about:accounts?action=signup&entrypoint=uitour

It can't trigger 'action=signin', so the best solution for now would be to either remove the link, or change it to something more valuable. 

Changing the about:accounts UITour action parameter would require a Fx engineering bug. Should be simple, but takes time.

Updated

2 years ago
Whiteboard: [kb=1787585]
(Assignee)

Comment 2

2 years ago
Hm, I *think* we were aware of this limitation/less than ideal flow when we decided to use the accounts.firefox.com link. AFAIK, it's the best experience we can offer at this time for a "sign in" link.

The chances of a user having a Firefox account but no existing profile are fairly low, though it can happen.

cc'ing habber to see if she has any thoughts.
Flags: needinfo?(hhabstritt.bugzilla)
(Reporter)

Comment 3

2 years ago
IMHO "sign in link that doesn't work" is a worse experience than "no sign in link at all".  Agreed that there's a low probability of triggering it in practice though.
Personally, I would vote for removing the link also. Even if it might only get clicked by a tiny percentage of users, if it doesn't actually do what's expected then it seems to only lead to confusion for those who do?
By removing the link completely, the assumption is that this user knows how to sign back into their account (for the purpose of Sync) via the Firefox menu (http://cl.ly/image/340M2c0U2I1m) or by finding the sign-in form another way. I'm not sure all users will know where to do this or even realize that they aren't signed in to begin with. However, for this edge case and until the new UI is implemented, this may work for an interim solution. 

Another option is for the "Already have one? Sign in." link to expand this menu and highlight the "sign into sync" option. We've done this in a past /firstrun or /whatsnew experience, so it should not require any new UITour or Fx engineering work. (correct, :agibson? Is this worth the amt of work it would take to implement?)


:jpetto, when this link is displayed within the iframe in our next iteration of /firstrun will we no longer have this issue?
Flags: needinfo?(jon)
Flags: needinfo?(hhabstritt.bugzilla)
Flags: needinfo?(agibson)
(In reply to Holly Habstritt Gaal [:Habber] from comment #5)
> By removing the link completely, the assumption is that this user knows how
> to sign back into their account (for the purpose of Sync) via the Firefox
> menu (http://cl.ly/image/340M2c0U2I1m) or by finding the sign-in form
> another way. I'm not sure all users will know where to do this or even
> realize that they aren't signed in to begin with. However, for this edge
> case and until the new UI is implemented, this may work for an interim
> solution.

Yep I totally agree, and can understand the rationale behind including the link. But if the functionality appears broken to a user who clicks the link, I do wonder if it is still justifiable to keep it given the current behavior.
  
> Another option is for the "Already have one? Sign in." link to expand this
> menu and highlight the "sign into sync" option. We've done this in a past
> /firstrun or /whatsnew experience, so it should not require any new UITour
> or Fx engineering work. (correct, :agibson? Is this worth the amt of work it
> would take to implement?)

Yep, I think this would be totally do-able. If we think there is enough value in keeping the link for the percentage of users who might hit this, then I think it sounds like a good idea.
Flags: needinfo?(agibson)
(Assignee)

Comment 7

2 years ago
When displayed in the iframe for Fx40, the "Already have an account? Sign in." link will load the sign-in view within the iframe. When the user successfully signs in via the iframe, they are signed in to sync in the browser, meaning this issue should be avoided altogether.

This can currently be tested on demo4 using the instructions posted here: https://bugzilla.mozilla.org/show_bug.cgi?id=1150231#c4
Flags: needinfo?(jon)
In the First Run Growth Team meeting today we landed on the following solution:
- remove the "Already have an account? Sign in." link
- clicking on the primary CTA will open the Firefox/hamburger menu and highlight "Sign in to Sync" menu item

This allows us to send both user types through the Sync sign-in flow which handles users w/ and w/out an account. The CTA copy does prioritize users that do not have an account (the most likely visitors to this experience), but will stop duplicate accounts from being created if a user w/ an existing account enters the flow. 
 

For Firefox 40, our iframe solution will allow us the ability to send users with a current account through the appropriate Sync sign-in flow via a link call-out just for this user.
(Assignee)

Updated

2 years ago
Assignee: nobody → jon
(Assignee)

Updated

2 years ago
Component: General → Pages & Content
OS: Mac OS X → All
Hardware: x86 → All
(Assignee)

Comment 9

2 years ago
Created attachment 8630688 [details] [review]
GitHub PR

Comment 10

2 years ago
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/80913d762b4fd8223a8ded5dbcbd669d22ac9daa
Bug 1177817. Update Fx 38.0.5 firstrun CTA.

https://github.com/mozilla/bedrock/commit/693040d914c96c23229fdf1b50dc9a6fc0e46b58
Merge pull request #3106 from jpetto/bug-1177817-update-38.0.5-firstrun

Bug 1177817. Update Fx 38.0.5 firstrun CTA.

Updated

2 years ago
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

2 years ago
Created attachment 8633254 [details]
new_accounts_rate.png

Sorry to be a total back-seat driver here, but can we please reconsider the switch of the CTA to trigger the "sign in to sync" hamburger dropdown?

We have seen a sharp fall in new FxA creations per day (see [1] or attached screenshot) and given that most of those are coming from the first-run flow, I wonder if this change is behind it.

The "sign in to sync" hamburger dropdown offers pretty much the same experience as the previous "about:accounts?action=signup&entrypoint=uitour" URL for users with an existing account:

  * it initially lands you on the "create a firefox account to continue to sync" page
  * you click the link at the bottom that says "already have an account? sign in"
  * you login with your existing credentials and are signed in to sync

So I wonder if bringing back "about:accounts?action=signup&entrypoint=uitour" as the primary CTA will give existing-account users an equivalent experience to the hamburger dropdown, while allowing a smoother funnel for new users.

Unless I'm missing something that means we *have* to use the dropdown, of course.

> This allows us to send both user types through the Sync sign-in flow which handles users w/
> and w/out an account.

To be clear, the "about:accounts" flow handles both types of user just fine.  They'll land on the "create an account page" but can easily get from there to the "sign in with an existing account" page.

> The CTA copy does prioritize users that do not have an account (the most
> likely visitors to this experience), but will stop duplicate accounts from being created if a
> user w/ an existing account enters the flow. 

There's no risk of creating duplicate accounts; if you try to sign up with an email that already exists, you'll get an error and be asked to sign in instead.


[1] https://metrics.services.mozilla.com/accounts-dashboard/
Flags: needinfo?(hhabstritt.bugzilla)

Updated

2 years ago
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 12

2 years ago
I'm re-opening this. I was on PTO when the decision was made to switch the CTA to open the hamburger menu vs the form, which is why bounce rate on Firefox accounts took a turn for the worse. The accounts sign up rates are almost back to the bad old days and that's not good.
(In reply to Ryan Kelly [:rfkelly] from comment #11)
> Created attachment 8633254 [details]
> new_accounts_rate.png
> 
> Sorry to be a total back-seat driver here, but can we please reconsider the
> switch of the CTA to trigger the "sign in to sync" hamburger dropdown?
> 
> We have seen a sharp fall in new FxA creations per day (see [1] or attached
> screenshot) and given that most of those are coming from the first-run flow,
> I wonder if this change is behind it.
> 
> The "sign in to sync" hamburger dropdown offers pretty much the same
> experience as the previous "about:accounts?action=signup&entrypoint=uitour"
> URL for users with an existing account:
> 
>   * it initially lands you on the "create a firefox account to continue to
> sync" page
>   * you click the link at the bottom that says "already have an account?
> sign in"
>   * you login with your existing credentials and are signed in to sync
> 
> So I wonder if bringing back
> "about:accounts?action=signup&entrypoint=uitour" as the primary CTA will
> give existing-account users an equivalent experience to the hamburger
> dropdown, while allowing a smoother funnel for new users.
> 
> Unless I'm missing something that means we *have* to use the dropdown, of
> course.
> 
> > This allows us to send both user types through the Sync sign-in flow which handles users w/
> > and w/out an account.
> 
> To be clear, the "about:accounts" flow handles both types of user just fine.
> They'll land on the "create an account page" but can easily get from there
> to the "sign in with an existing account" page.
> 
> > The CTA copy does prioritize users that do not have an account (the most
> > likely visitors to this experience), but will stop duplicate accounts from being created if a
> > user w/ an existing account enters the flow. 
> 
> There's no risk of creating duplicate accounts; if you try to sign up with
> an email that already exists, you'll get an error and be asked to sign in
> instead.
> 
> 
> [1] https://metrics.services.mozilla.com/accounts-dashboard/



In order to determine if the interaction alone is causing this, it sounds like we should allow the primary CTA/button to point to about:accounts?action=signup&entrypoint=uitour where it was before. This way we're trying to get the new account user metrics back on track

In order to not leave the current account users wondering where to sign in, it would be best to bring back the "already have an account? sign in" below the button, but have this link open the hamburger menu. However, Cmore just mentioned that there is a bug with how the hamburger menu is opening.

If there is no way to resolve that bug, we will have to remove that link all together and rely on current account users finding a way to sign in on their own. (opening hamburger menu themselves or clicking "sign up" and finding their way to the sign in form.
Flags: needinfo?(hhabstritt.bugzilla)
(In reply to Chris More [:cmore] from comment #12)
> I'm re-opening this. I was on PTO when the decision was made to switch the
> CTA to open the hamburger menu vs the form, which is why bounce rate on
> Firefox accounts took a turn for the worse. The accounts sign up rates are
> almost back to the bad old days and that's not good.

Chris, can you explain more about your comment in the email thread regarding the Firefox bug where the hamburger menu does not always open? I was not aware of this. Is it anything we can fix? If not, we shouldn't rely on this flow.

Comment 15

2 years ago
I can replicate the open hamburger menu issue. It happened a few times on the first click and now it happens on the second click. This may be what Shane experienced that he said later worked fine. He said he clicked the CTA and nothing happened and then tried again later and it worked.

If go here in Firefox 39:

https://www.mozilla.org/en-US/firefox/39.0/firstrun/

Click 1: open menu
Click 2: close menu
Click 3: nothing
..
Click N: nothing
Refresh
Works

During testing tonight, I had it happen once on the first click. Shane can probably explain what he saw too.

Comment 16

2 years ago
I tried the menu issue above on a new profile and could replicate it.
(In reply to Chris More [:cmore] from comment #16)
> I tried the menu issue above on a new profile and could replicate it.


Getting new accounts for /firstrun is a priority, so regardless we should change main CTA back to pointing to ?action=signup. 

If the hamburger menu continues to work intermittently and is not an easy fix, let's not rely on it. In this case we can:
1) point main CTA to ?action=signup for new users (most /firstrun traffic) 
2) below main CTA have a link "already have an account?" point the existing user to a SUMO article that explains how to sign in.  (this is a nice alternative to not having an explicit link for existing accounts and making them find this info on their own)
(In reply to Chris More [:cmore] from comment #15)
> I can replicate the open hamburger menu issue. It happened a few times on
> the first click and now it happens on the second click. This may be what
> Shane experienced that he said later worked fine. He said he clicked the CTA
> and nothing happened and then tried again later and it worked.
> 
> If go here in Firefox 39:
> 
> https://www.mozilla.org/en-US/firefox/39.0/firstrun/
> 
> Click 1: open menu
> Click 2: close menu
> Click 3: nothing
> ..
> Click N: nothing
> Refresh
> Works
> 
> During testing tonight, I had it happen once on the first click. Shane can
> probably explain what he saw too.

This looks like an implementation bug, rather than a UItour/flow issue. The page binds a click event handler on document to hide the menu once opened, so there is likely a race condition going on when following the above steps. It is very unlikely anything to do a users' profile, or the UITour event itself. This issue has probably been there since the new page launched.

Also, +1 for linking directly to about:accounts like it used to (this offers a flow with much less friction / clicks required).
(Assignee)

Comment 19

2 years ago
I can confirm the hamburger menu CTA bug has been present since the 38.0.5 firstrun page launched. Alex is correct - there is a race condition occurring when clicking the CTA multiple times in succession. The fix is relatively simple and can be implemented/pushed immediately, or along side other updates to the page later today.

Comment 20

2 years ago
Nice investigation, Alex! It does seem like a race condition.
Thanks for the quick investigation! The FxA team and I were trying to pinpoint the problem yesterday, but I fear I caused more of a panic than offering any real information.

Comment 22

2 years ago
How about this flow:

CTA: Link to the about:accounts form like previously

Already have an account link: Trigger uiTour open hamburger menu and highlight sign in

Seems like that would optimize both use-cases until we get to Firefox 40 where all of this will be better.
(Assignee)

Comment 23

2 years ago
(In reply to Chris More [:cmore] from comment #22)
> How about this flow:
> 
> CTA: Link to the about:accounts form like previously
> 
> Already have an account link: Trigger uiTour open hamburger menu and
> highlight sign in
> 
> Seems like that would optimize both use-cases until we get to Firefox 40
> where all of this will be better.

I think this proposed UX/flow is about as good as we can get prior to embedding the form in Fx 40.

Signing up has as little friction as possible. Signing in via the hamburger menu provides good product training for users with existing accounts.

+1 for moving forward with this flow.
(In reply to Jon Petto [:jpetto] from comment #23)
> (In reply to Chris More [:cmore] from comment #22)
> > How about this flow:
> > 
> > CTA: Link to the about:accounts form like previously
> > 
> > Already have an account link: Trigger uiTour open hamburger menu and
> > highlight sign in
> > 
> > Seems like that would optimize both use-cases until we get to Firefox 40
> > where all of this will be better.
> 
> I think this proposed UX/flow is about as good as we can get prior to
> embedding the form in Fx 40.
> 
> Signing up has as little friction as possible. Signing in via the hamburger
> menu provides good product training for users with existing accounts.
> 
> +1 for moving forward with this flow.

If the hamburger menu issue is all cleared up, then +1 to this.

Comment 25

2 years ago
Commits pushed to master at https://github.com/mozilla/bedrock

https://github.com/mozilla/bedrock/commit/342d134b65ace004ea3608c39dc7391d58601361
[fix bug 1177817] Update 38.0.5 firstrun sign in/up CTAs.

https://github.com/mozilla/bedrock/commit/b8753d951307ed5324eea0a1052be218eae24097
Merge pull request #3143 from jpetto/bug-1177817-refactor-38.0.5-firstrun

[fix bug 1177817] Update 38.0.5 firstrun sign in/up CTAs.

Updated

2 years ago
Status: REOPENED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.