777.54 KB, video/quicktime
46 bytes, text/x-github-pull-request
|Details | Review | Splinter Review|
2.64 MB, video/mp4
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.
Can we get a video of the bug?
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.
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?
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".
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.
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.
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.
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+
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
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)
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)
Also, I think we want to flag this bug late-l10n, but I don't seem to have access to do that.
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).
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+
Finally looks green in my branch's travis: https://travis-ci.org/6a68/gaia/builds/27443509 Merging.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: 2.0 S5 (4july) → 2.0 S4 (20june)
status-b2g-v2.0: --- → fixed
status-b2g-v2.1: --- → fixed
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
You need to log in before you can comment on or make changes to this bug.