1037232 - [B2G][FindMyDevice] Find My Device displays Sign in/Create account when signed into an account is not Verified

Status: VERIFIED FIXED

(Firefox OS Graveyard :: FindMyDevice, defect)

Description

[Jordan de Geus(JordanD)]

Attachment: Logcat_fmd.txt

Description:
When users have an account confirmed but not verified that is signed in, the users will see a button under Find My Device that states Sign in or Create account but the button lacks functionality. 


Repro Steps:
1) Update a Flame device to BuildID: 20140708000322
2) Set Flame to 273mb and reboot device
3) Navigate to Settings> Find My Device> Sign In or Create an Account> Progress through account sign up
4) After signing up for account, dismiss "Confirm Your Account" (Note: Do not confirm Firefox Account)
5) Observe users see a button to Sign in or Create account but the button lacks functionality


Actual:
Find My Device contains a Sign in or Create account that lacks functionality
Expected:
Find My Device displays contains a functional button

Environmental Variables:
Device: Flame 2.0 (273mb)
BuildID: 20140710000201
Gaia: 35a9b715e7348ec738ff6c8a59f50190390a06f2
Gecko: 94714370dfc3
Version: 32.0a2
Firmware Version: v122
2.0 - Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Repro frequency: 5/5
See attached: Logcat and Video attached
Logcat_account.txt - Video - http://youtu.be/DeBQVYhIEMA

Comment 1

[Jordan de Geus(JordanD)]

This issue DOES occur on Flame 2.0 (512mb), Flame 2.1 (273mb), Buri 2.0 and Buri 2.1

Flame 2.1 (273mb)

Environmental Variables:
Device: Flame Master
Build ID: 20140710040201
Gaia: 4e4e579b4b1e35f863ed43ef6ba840f49bfd761c
Gecko: cb75d6cfb004
Version: 33.0a1 (Master)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Flame 2.0(512mb)

Environmental Variables:
Device: Flame 2.0
BuildID: 20140710000201
Gaia: 35a9b715e7348ec738ff6c8a59f50190390a06f2
Gecko: 94714370dfc3
Version: 32.0a2 (2.0) 
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0


Buri 2.1 

Environmental Variables:
Device: Buri Master
Build ID: 20140710071930
Gaia: 09642e74e250fbc62db860c808ef188628fca55d
Gecko: f93c0ef45597
Version: 33.0a1 (Master)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0


Buri 2.0

Environmental Variables:
Device: Buri 2.0
Build ID: 20140710000201
Gaia: 35a9b715e7348ec738ff6c8a59f50190390a06f2
Gecko: 94714370dfc3
Version: 32.0a2 (2.0)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Actual: Users will see the "Sign in or Create a firefox account" button but lacks functionality

--------------------------------------------------------------------

This issue DOES NOT occur on Buri 1.4 and Flame 1.4 as Find My Device was not available.

Buri 1.4

Environmental Variables:
Device: Buri 1.4
Build ID: 20140710000202
Gaia: b0e9b4bdb39c5eb93a6783a34624ffc84f62b126
Gecko: ccabaf8826a4
Version: 30.0 (1.4)
Firmware Version: v1.2device.cfg
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Flame 1.4

Environmental Variables:
Device: Flame 1.4
Build ID: 20140710000202
Gaia: b0e9b4bdb39c5eb93a6783a34624ffc84f62b126
Gecko: ccabaf8826a4
Version: 30.0 (1.4)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Comment 2

[KTucker [:KTucker][Inactive 3/4/2016]]

This is bad user flow. The user should be taken back to the "Confirm Your account" screen if anything to avoid the non-functional "sign in/create account" button. Kate, can you weigh in on the severity of this issue? Should this be nominated 2.0?

Comment 3

[Kate Glazko]

Hi all, I filed this bug a while earlier https://bugzilla.mozilla.org/show_bug.cgi?id=1033021 and it was duped to the OneCallback() bug.

I can CC :elan on this bug to confirm whether or not this is a blocker.

Comment 4

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

Maybe we can reuse the string from the fxa settings app menu screen? "please verify [e-mail]"

It would be a bit cryptic, but probably better than nothing (which is what we currently have).

It's here, for reference: https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/locales/settings.en-US.properties#L706

Comment 5

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

:ggp in IRC pointed out that the fix for this bug might conflict with the fix for bug 1034088, which is currently out for review. This bug should wait till that one lands.

Comment 6

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

:ggp I would probably like to hand this one off, since you've been working on a related bug. How's that sound?

Comment 7

[Guilherme Gonçalves [:ggp]]

Sure.

Comment 8

[Guilherme Gonçalves [:ggp]]

We're correctly calling navigator.mozId.request() in the Settings app while the unverified account is logged in; however, in that case FxA just triggers onerror and does not present any UI, and neither do we.

There are two possible solutions here: either FxA could bring up its "Confirm your account" UI in that case (in addition to firing onerror), or FMD could handle the error and display its own UI, much like we already do when the device is offline.

:spenrose and I believe the former provides a more elegant UI overall, but we have no idea how risky it is to implement now. The second shouldn't be too hard, especially if we can reuse FxA's strings. Jared, what do you think?

Comment 9

[Preeti Raghunath(:Preeti)]

[Blocking Requested - why for this release]:
Wouldn't block the release and hence backlog

Comment 10

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

(In reply to Guilherme Gonçalves [:ggp] from comment #8)
> We're correctly calling navigator.mozId.request() in the Settings app while
> the unverified account is logged in; however, in that case FxA just triggers
> onerror and does not present any UI, and neither do we.
> 
> There are two possible solutions here: either FxA could bring up its
> "Confirm your account" UI in that case (in addition to firing onerror), or
> FMD could handle the error and display its own UI, much like we already do
> when the device is offline.

So, the first case. Are we talking about a flow along the lines of:

1. user creates FxA account
2. user opens FMD app
3. onerror fires
4. FxA displays "please verify your account" over top of the RP app?

It seems strange to me that FxA would both fire an error callback and display some UI on behalf of the app--if we were to do this, we'd probably want it to be possible for apps to not display the error UI, and handle it gracefully themselves. Seems like an odd user experience overall, even harder for RPs to integrate. Maybe I'm not understanding the proposed flow, though?

The second proposal keeps FxA's involvement in RP UI limited to firing callbacks, which seems more in line with other WebAPIs.
  We could definitely try to reuse strings, but we're past feature complete, and this bug has been backlogged, so I'm not sure it's worth attempting to land for 2.0. If Vishy (ni'd) wants to promote this to a blocker, then yeah, we could certainly just show "please verify [e-mail]" in the FxA panel in this case.
  If we're talking about landing this for 2.1, then I'd say we should close out this bug and instead raise the issue of error flows with product and UX, and try to insert these concerns into the product process at the very top, rather than hacking something together here at the last minute.

Comment 11

[Guilherme Gonçalves [:ggp]]

(In reply to Jared Hirsch [:_6a68] [@6a68] from comment #10)
> So, the first case. Are we talking about a flow along the lines of:
> 
> 1. user creates FxA account
> 2. user opens FMD app
> 3. onerror fires
> 4. FxA displays "please verify your account" over top of the RP app?

I'm thinking the UI would only be triggered after the RP app calls request(), much like the login UI is triggered after a request() when nobody is logged in.

> 
> It seems strange to me that FxA would both fire an error callback and
> display some UI on behalf of the app

I'm seeking inspiration on the login flow, in which request() displays a UI and fires onlogin. This is a detail though, we can discuss further if we go this way.

>   We could definitely try to reuse strings, but we're past feature complete,
> and this bug has been backlogged, so I'm not sure it's worth attempting to
> land for 2.0. 

Yeah, the bug got backlogged shortly after my comment, we should definitely reach
a consensus for how important this is before discussing the solution. I personally
would like to see this fixed for 2.0, given that it's fairly low-risk and it's
user-visible, but I can also see this being dismissed as an unlikely corner case.

> If we're talking about landing this for 2.1, then I'd say we should close
> out this bug and instead raise the issue of error flows with product and UX,
> and try to insert these concerns into the product process at the very top,
> rather than hacking something together here at the last minute.

+1

Comment 12

[vkrishnamoorthy]

I think that this is common enough occurrence for us to fix for 2.0. Ggp: Jared: what is the risk assessment for a potential fix? Jacqueline could you weigh in from a UX perspective?

Ideally we should provide some UX to prompt the user to complete the verification step.

If the fix is too risky and cannot be uplifted to 2.0, we need SUMO to provide information on this issue

Comment 13

[Jared Hirsch [:jhirsch] (he/him) (Needinfo please)]

The simplest fix I can think of would be to insert the FxA string "Please verify [e-mail]" into the FMD settings panel, and hide the 'sign in' button. The string is a bit cryptic, but at least gives the user a clue, and the string is already available inside the Settings app. Seems like an easy fix to me.

Comment 14

[Jacqueline Savory [:jsavory] UX]

I think that Jared's suggestion sounds good to me. I'm just wondering if we are able to use some of the strings that are in the Firefox Accounts page?

For example, we could disable the Sign in button and add the strings:
"We will send an email to: [e-mail]"  
"Click the verification link in your email to confirm your account."

If we can't use these strings, then Jared's suggested string works as well.

Comment 15

[Guilherme Gonçalves [:ggp]]

I'm also OK with Jared's suggestion. I still think it would be good to get FxA support on this, but as a quick low-risk solution, re-using FxA's string sounds good.

Perhaps we could just display the string after the Sign In button is clicked, rather than hiding the button entirely?

Comment 16

[Michael:mtreese]

[Blocking Requested - why for this release]:

Comment 17

[Guilherme Gonçalves [:ggp]]

Attachment: gaia pull request

This PR implements Jared's suggestion.

Comment 18

[Jason Smith [:jsmith]]

(In reply to Michael:mtreese from comment #16)
> [Blocking Requested - why for this release]:

Michael - Can you clarify why you have nominated this bug to block?

Comment 19

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 8466200 [details] [review]
gaia pull request

r=me, thanks!

Comment 20

[Guilherme Gonçalves [:ggp]]

Thank you!

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Master: https://github.com/mozilla-b2g/gaia/commit/7c9bf2c8e6e82001a0b9c603d3765dd4bae311e0

Comment 22

[Jason Smith [:jsmith]]

Given Vishy's comment, we've decided to block on this.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/9dbe45c9319c2d2e4900b913eb1579f4722719a2

Comment 24

[Shine(Leave from Mozilla)]

Attachment: video

This issue has been verified successfully on Flame 2.0 and 2.1
See attachment: Verify_1037232.MP4
Reproducing rate: 0/3
Verify Steps:
1.  Set Flame to 273mb and reboot device
2.  Navigate to Settings> Find My Device> Sign In or Create an Account
3.  Input an account > Tap Next button > Select Year of Birth > Create a Password and tap Next button > Tap Done
** It go back to “Find My Device” screen, it display the string: Click the verification link in your email to confirm your account.

Flame 2.0 build:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3
Build-ID        20141130000204
Version         32.0

Flame 2.1 build:
Gaia-Rev        ccb49abe412c978a4045f0c75abff534372716c4
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22
Build-ID        20141130001203
Version         34.0