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

VERIFIED FIXED in Firefox OS v2.0

Status

Firefox OS
FindMyDevice
VERIFIED FIXED
4 years ago
2 years ago

People

(Reporter: pdehaan, Assigned: _6a68)

Tracking

({late-l10n})

unspecified
2.0 S4 (20june)
x86
Mac OS X
late-l10n
Dependency tree / graph

Firefox Tracking Flags

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

Details

(Whiteboard: [2.0-FL-bug-bash] )

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
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.

Updated

4 years ago
Whiteboard: [2.0-FL-bug-bash]
Can we get a video of the bug?
Keywords: qawanted

Comment 2

4 years ago
Created attachment 8436631 [details]
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.

Updated

4 years ago
QA Contact: kglazko
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.
blocking-b2g: --- → 2.0?
Keywords: qawanted

Updated

4 years ago
Assignee: nobody → elancaster

Comment 4

4 years ago
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

4 years ago
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.
(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

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

Yes.
(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

4 years ago
Ok, that sounds good. This will be addressed during the walk-through tomorrow.
(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.
See Also: → bug 1013423
Blocking on this as QA confirmed this would be a potential issue in the target markets and TEF would need this.
blocking-b2g: 2.0? → 2.0+

Updated

4 years ago
Depends on: 998489, 1013423

Updated

4 years ago
Assignee: elancaster → nobody

Updated

4 years ago
Target Milestone: --- → 2.0 S5 (4july)
(Assignee)

Comment 13

4 years ago
Stealing. Current plan:

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

Should be easy, we'll see.
Assignee: nobody → 6a68
(Assignee)

Comment 14

4 years ago
Created attachment 8438798 [details] [review]
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
Attachment #8438798 - Flags: review?(arthur.chen)
(Assignee)

Comment 15

4 years ago
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
Attachment #8438798 - Flags: feedback?(francesco.lodolo)
(Assignee)

Comment 16

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

Updated

4 years ago
Keywords: late-l10n
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.
Attachment #8438798 - Flags: feedback?(francesco.lodolo) → feedback-
Looks good to me, thank you so much for helping out with this! I left a couple of minor comments on GitHub.
Comment on attachment 8438798 [details] [review]
Github PR 20391

Looks good to me.
Attachment #8438798 - Flags: review?(arthur.chen) → review+
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).
(Assignee)

Comment 21

4 years ago
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.
Attachment #8438798 - Flags: feedback- → feedback?(francesco.lodolo)
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 ;-)
Attachment #8438798 - Flags: feedback?(francesco.lodolo) → feedback+
(Assignee)

Comment 23

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

Merging.
(Assignee)

Comment 24

4 years ago
Master: https://github.com/mozilla-b2g/gaia/commit/8c533eaec4ec65298dd31f6d6c89a6f8e7ef8258
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: 2.0 S5 (4july) → 2.0 S4 (20june)
v2.0: https://github.com/mozilla-b2g/gaia/commit/ea91278d4511ec8b35105ff1b98d144c82077ae3
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: --- → fixed

Updated

4 years ago
Depends on: 1027422

Updated

4 years ago
Depends on: 1027950
Created attachment 8531878 [details]
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
status-b2g-v2.0: fixed → verified
status-b2g-v2.1: fixed → verified
Status: RESOLVED → VERIFIED
Duplicate of this bug: 998489
You need to log in before you can comment on or make changes to this bug.