1014077 - Create navigator.mozAccounts as an alias for navigator.mozId

Status: RESOLVED INVALID

(Firefox OS Graveyard :: FxA, defect, P2)

Description

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Presently, Firefox Accounts and Persona have similar APIs.  They are both implemented natively in navigator.mozId (dom/identity/nsDOMIdentity.js and so on).

Although Firefox Accounts and Persona met in this common middle ground, they are moving apart from each other.  Persona is moving away from the stateful observer API, and Firefox Accounts needs to support device- and Firefox-specific extensions.  So they are going to need separate native implementations.

spenrose, callahad, and I have spoken about moving Firefox Accounts away from mozId and creating navigator.mozAccounts for it instead.

We have, however, a very small window of a few weeks to do this in time for the FxOS 2.0 release, which will use Firefox Accounts with Marketplace and FMD.  It feels unlikely, and at best highly risky, that we would land a complete replacement implementation for mozAccounts across three modules (dom, toolkit, b2g) in the next few weeks.  Yet if we don't make it possible for Marketplace, FMD, et al., to use navigator.mozAccounts in 2.0, we will have a miserable dual-API situation in future releases.

Therefore, I suggest that for this initial release, we make navigator.mozAccounts an alias for navigator.mozId, with no change in its current functionality, with the intention of separating the two APIs from each other in the 2.1 development cycle.  This will enable us to get Marketplace and FMD onto navigator.mozAccounts right away, with Persona and Firefox Accounts being able to evolve in different directions in future releases transparently to our clients.

Bug 1009849 (API versioning for mozId) will also help resolve possible confusion in the future.

Comment 1

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Thanks to :bz and :bholley for their help in answering my questions.  It sounds like we have several good options here, so hopefully we can make a smooth and minimally-tricky way forward.

First, I think we should start simple and try to make mozId and mozAccounts each a separate instance of the identity service.  This should be accomplished simply by adding to our Identity.manifest:

  category JavaScript-navigator-property mozAccounts @mozilla.org/dom/identity;1

Subsequently, since we have been asked to move mozId to a webidl implementation, we would create an identity webidl file with separate interfaces for mozId and mozAccounts, and each of those interfaces possessing extended attributes declaring a different NavigatorProperty (one for mozId, one for mozAccounts).  At this point, we could more easily begin to grow mozAccounts and mozId in different directions.

Hopefully it's as easy as it sounds, and having two distinct instances of @mozilla.org/dom/identity;1 won't cause any problems.  Fingers crossed ...

Comment 2

[Fernando Jiménez Moreno [:ferjm]]

Thanks for starting this, Jed.

Is the WebAPI team aware of this change? If we are finally moving the FxA RP API away from mozId it would be great if we could take the opportunity to review the whole API with the help of the WebAPI team.

On a side note, we could probably also get rid of the FxA management API built with the IAC API adding something like navigator.mozAccounts.mgmt for certified apps, but that's probably another discussion.

Comment 3

[(no longer active)]

This is the first I'm hearing about this API.

Is this API targeted at certified only apps?  Or towards something less restrictive?  If this is targeted at certified apps only, then we can basically do whatever we want here, otherwise we may not want to expose the API until we know exactly what it will look like, etc.  And it looks like so far we don't really know what we're going to do with this API exactly.

Jed, can you please start a thread on dev-webapi about this and provide some details on what the goal here is, etc.?  Thanks!

Comment 4

[Jed Parsons (use needinfo, please) [:jedp, :jparsons]]

Having spoken more with the team, we've decided this isn't the way we want to go.  Thanks, Fernando and Ehsan, for your feedback.