Closed Bug 1027432 Opened 11 years ago Closed 11 years ago

Stop assuming FxA's onready will fire only once in the Find My Device app

Categories

(Firefox OS Graveyard :: FindMyDevice, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: ggp, Assigned: ggp)

References

Details

Bug 1027422, except in the Find My Device app rather than Settings.
Sam, in this bug and bug 1027422, we found out that onready fires after onlogin/onlogout, every time. Based on the documentation on MDN for the watch() API for Persona [1] (I know, I know...) I had assumed it would only ever fire once, when the API was ready to start receiving request() calls, and not after every other event fires. Can you confirm that this is intended behavior? If so, maybe we should file a bug somewhere to get this documentation updated or clarified? 1- https://developer.mozilla.org/en-US/docs/Web/API/navigator.id.watch
Flags: needinfo?(spenrose)
Guilherme: honestly I don't know. It sounds like you are expecting the first sentence here to override the second: "A function that will be invoked when the user agent is initialized and able to process calls to id.request and id.logout. The onready callback will be invoked immediately after any automatic invocations of onlogin, onlogout, or onmatch." and that may be very sensible. Jed, can you give us some historical perspective on how onready() should behave?
Flags: needinfo?(spenrose) → needinfo?(jparsons)
Jed tells me that the current behavior is correct: onready() should fire after each onlogin/onlogout.
Flags: needinfo?(jparsons)
Invalid, sorry to have caused a panic :beers:
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → INVALID
(In reply to Sam Penrose from comment #2) > and that may be very sensible. Jed, can you give us some historical > perspective on how onready() should behave? We've had a good conversation about this on irc, and I think it's all straightened out. The root cause was elsewhere. ggp's reading in Comment 1 is correct. I'll summarize onready() here for posterity. The BrowserID spec [1] says this about onready: A function that will be invoked when the user agent is initialized and able to process calls to id.request and id.logout. The onready callback will be invoked immediately after any automatic invocations of onlogin, onlogout, or onmatch. By waiting to display UI until onready is called, relying parties can avoid UI flicker in cases where the user agent's preferred state is out of sync with the site's session. This has caused some confusion in the past as well, and the API itself is not universally adored. See for example Bug 945363, especially comments 17 and following. In a nutshell, onready() is the final punctuation mark that concludes the conversation begun by watch(). According to the spec, when you call watch(), eventually your onready() callback will be invoked, signifying that the system is ready to go and you may now call request() or logout(). In the mean time, it's possible that you'll have received an automatic call to onlogin() or onlogout() as a result of calling watch(). Those will always be invoked before onready(). Thus you can prepare your UI according to the current signed-in-user state and finally enable your interface when onready() is called. If you then call request(), once the user logs in, onlogin() will be invoked. You will not get an onready() call after request(). Nor will you get an onready() after a logout(). Only after watch(). The Firefox Accounts test suite has some examples demonstrating the various possible sequences of callbacks, depending on the initial logged-in-user state [2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/navigator.id.watch [2] https://mxr.mozilla.org/mozilla-central/source/toolkit/identity/tests/unit/test_firefox_accounts.js
You need to log in before you can comment on or make changes to this bug.