Closed
Bug 1013423
Opened 11 years ago
Closed 7 years ago
Handle registration failing due to the server being unreachable
Categories
(Firefox OS Graveyard :: FindMyDevice, defect)
Firefox OS Graveyard
FindMyDevice
Tracking
(tracking-b2g:backlog)
RESOLVED
WONTFIX
tracking-b2g | backlog |
People
(Reporter: ggp, Unassigned)
References
Details
We need to define the client-side behavior and UX for when registration fails due to the server being unreachable (which can happen because of a network error, for example).
Please see bug 966033 for my early exploration on this, in both client behavior and appearance. I would expect the UX solution for this to be similar to the one we take on 998489, but this would be place to decide it.
Updated•11 years ago
|
Assignee: ggoncalves → jsavory
Updated•11 years ago
|
feature-b2g: --- → 2.0
Comment 2•11 years ago
|
||
It sounds like you could use the generic error message we're using on Firefox Accounts on lines 47-48. If it's a matter of the user not having their network enabled, lines 35-36. Both of these are displayed in error sheets.
https://github.com/mozilla-b2g/gaia/blob/master/apps/system/fxa/locales/fxa.en-US.properties
feature-b2g: 2.0 → ---
Comment 3•11 years ago
|
||
Tagging late l10n so it's understood that the at least one set of strings mentioned above will be used for the gaia client.
Keywords: late-l10n
Reporter | ||
Updated•11 years ago
|
Comment 4•10 years ago
|
||
late-l10n keyword is not useful in these cases, better to cc someone from l10n-drivers to get advice if you have doubts.
So, you plan to reuse 2/4 strings from Firefox Accounts for Find My Device. As long as the context is the same (font-size, role of the text, etc.) it should be fine.
Probably worth having some generic error messages to reuse across apps in 2.1?
Keywords: late-l10n
Comment 6•10 years ago
|
||
Bug 1021428 handles the case of being offline before registration is initiated.
We have yet to test what happens if registration fails due to server being unreachable, for example, if one has wifi and then loses wifi connection in the middle of attempting to register, or if the server goes down when one is registering.
This isn't trivial to test, and not certain whether Bug 1021428 is enough to handle this situation.
Updated•10 years ago
|
Assignee: jgruen → 6a68
Comment 7•10 years ago
|
||
Actually, maybe this bug doesn't need to land for 2.0.
There is a similar bug in FxA, and it was decided that, if we detect network offline at the start of the flow, catching network outages during the flow wouldn't block 2.0. See bug 998464, especially https://bugzilla.mozilla.org/show_bug.cgi?id=998464#c8, as well as the linked bug 1026603
Flags: needinfo?(elancaster)
Comment 8•10 years ago
|
||
+1 I'm good with aligning with an established FxA convention. Let's get this feature to market and see what users think, too.
Flags: needinfo?(elancaster)
Comment 9•10 years ago
|
||
Clearing qawanted since this isn't trivial to analyze & non-blocking issue.
Keywords: qawanted
Updated•10 years ago
|
feature-b2g: --- → 2.1
Updated•10 years ago
|
feature-b2g: 2.1 → ---
Comment 11•10 years ago
|
||
this is not a release blocker also ni jsavory.
:jsavory is this covered in the wireframes?
blocking-b2g: 2.1? → backlog
Assignee | ||
Updated•10 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
Updated•7 years ago
|
Assignee: jhirsch → nobody
Updated•7 years ago
|
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•