1021428 - Find my Device is awkward UX when you aren't connected to wifi or internet

Status: VERIFIED FIXED

(Firefox OS Graveyard :: FindMyDevice, defect)

Description

[Peter deHaan [:pdehaan]]

STR:
1. Pull any SIM cards and disable wifi.
2. Go to Settings > Find my Device.
3. Click on "Sign in or Create an Account" button.

Actual results:
Nothing happens. Tapping the button causes the blue highlight to appear but I don't seem to be able to proceed.

Comment 1

[Jason Smith [:jsmith]]

Can we get a video of the bug?

Comment 2

[Kate Glazko]

Attachment: Video recording of interaction with FMD, no Sim Card, no Wifi

Reproduced on Kindle Flame.

1.) Remove Sim Card
2.) Disable Wifi
3.) Click on FindMyDevice in settings, interaction should be same as described in bug.

Comment 3

[Jason Smith [:jsmith]]

We need to get this fixed. This is poor UX as it stands, as there's a button here that does nothing & provides no user feedback.

Comment 4

[Kate Glazko]

A proposed fix could be something as simple as instead of a sign-in button when a device detects no wi-fi or cellular data, a simple message that reads "Please enable a wifi or cellular data connection to use FindMyDevice".

Comment 5

[Kate Glazko]

Hopefully not a 2.0 blocker, looked at code, an easy GUI fix and a case in the FMD JS code that handles no internet connection should be all that's necessary to resolve this.

Comment 6

[Jason Smith [:jsmith]]

(In reply to kglazko from comment #5)
> Hopefully not a 2.0 blocker, looked at code, an easy GUI fix and a case in
> the FMD JS code that handles no internet connection should be all that's
> necessary to resolve this.

Why wouldn't we block on this? There's no user feedback here, so a user would not understand what was wrong with the feature. Our target markets also have poor network connections as well, so this can definitely happen in the field.

Comment 7

[Kate Glazko]

Would blocking on this prevent the feature from being released in 2.0?

Comment 8

[Jason Smith [:jsmith]]

(In reply to kglazko from comment #7)
> Would blocking on this prevent the feature from being released in 2.0?

Yes.

Comment 9

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #8)
> (In reply to kglazko from comment #7)
> > Would blocking on this prevent the feature from being released in 2.0?
> 
> Yes.

Well, yes if it's not fixed. Although I'm expecting someone will probably fix this in time during the stabilization period.

Comment 10

[Kate Glazko]

Ok, that sounds good. This will be addressed during the walk-through tomorrow.

Comment 11

[Jason Smith [:jsmith]]

(In reply to kglazko from comment #10)
> Ok, that sounds good. This will be addressed during the walk-through
> tomorrow.

Just to clarify btw - this isn't a FL blocker. But it's something we need to get fixed during the 2.0 stabilization timeframe.

Comment 12

[bhavana bajaj [:bajaj]]

Blocking on this as QA confirmed this would be a potential issue in the target markets and TEF would need this.

Comment 13

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

Stealing. Current plan:

- if !navigator.onLine, show a system dialog with a string lifted from fxa system app

Should be easy, we'll see.

Comment 14

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

Attachment: Github PR 20391

Hi Arthur!

I'm fixing a bug for Find My Device, this is a 2.0 blocker. Would you mind taking a look?

The underlying bug here is that navigator.mozId.watch fires an onerror callback if there is no network, but the existing code assumed onready would always fire. So, since the login button was wired up inside the onready handler, if onerror fired, the button would never work, even after the network was enabled.

Thanks very much!

Jared

Comment 15

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

Comment on attachment 8438798 [details] [review]
Github PR 20391

Hi Francesco,

My understanding is that fmd is reusing some fxa strings, in order to get things built before 2.0 string freeze, without having to go through the copy review process.

I've accordingly swiped an fxa error string and used it here. It reads a bit awkwardly, but I thought it's better UX than it was before, and probably better not to modify the existing approved strings.

Happy to leave off the "from Settings" part at the end if you think we can get that done rapidly.

This bug is a 2.0 blocker, so time is unfortunately of the essence.

Thanks very much,

Jared

Comment 16

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

Also, I think we want to flag this bug late-l10n, but I don't seem to have access to do that.

Comment 17

[Francesco Lodolo [:flod]]

Comment on attachment 8438798 [details] [review]
Github PR 20391

This PR introduces a new string, using the same string from a different file with a different ID is not reusing, for localizers it's a brand new string. 

You have 2 choices at this point:

1. Fix the string for real (with the best string possible) and use the new ID in this file, mark the bug as late-l10n

2. Actually reuse an existing string, but I can't see anything useful in settings.properties.

Comment 18

[Guilherme Gonçalves [:ggp]]

Looks good to me, thank you so much for helping out with this! I left a couple of minor comments on GitHub.

Comment 19

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

Comment on attachment 8438798 [details] [review]
Github PR 20391

Looks good to me.

Comment 20

[Francesco Lodolo [:flod]]

Just to clarify my f-: in fxa those are two separate strings.

Title: Unable to connect
Message: Please connect to a network from Settings.

When there is only one string, I usually see the format "Connect to the internet to DOSOMETHING", or "You must be connected to DOSOMETHING". If we're adding a string and breaking string freeze, it would be better to add the right one (but I'm not the one deciding it).

Comment 21

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

Comment on attachment 8438798 [details] [review]
Github PR 20391

Hi Francesco,

Ah, I didn't realize that it wasn't ok in this case to concat the two approved strings.

Since FxA doesn't have anything that makes UX sense on its own, I've lifted a string from the email app that seems to work fine as-is.

Comment 22

[Francesco Lodolo [:flod]]

Comment on attachment 8438798 [details] [review]
Github PR 20391

String looks definitely better. Note that this discussion has actually nothing to do with l10n, it's just ux+copy stuff ;-)

Comment 23

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

Finally looks green in my branch's travis: https://travis-ci.org/6a68/gaia/builds/27443509

Merging.

Comment 24

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

Master: https://github.com/mozilla-b2g/gaia/commit/8c533eaec4ec65298dd31f6d6c89a6f8e7ef8258

Comment 25

[Ryan VanderMeulen [:RyanVM]]

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

Comment 26

[Lancy(Leave from Mozilla)]

Attachment: Verify_Video_Flame.MP4

This issue has been verified successfully on Flame 2.0 & 2.1.
See attachment: Verify_Video_Flame.MP4
Reproducing rate: 0/10

Flame v2.0 version:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/29222e215db8
Build-ID        20141203000201
Version         32.0

Flame v2.1 version:
Gaia-Rev        dbaf3e31c9ba9c3436e074381744f2971e15c7bf
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194
Build-ID        20141203001205
Version         34.0