The only wrinkle is that we don't always have an Activity context, so
we always start a new task. We might want to revisit that decision.
--HG--
extra : commitid : Liun7Xv30B5
extra : rebase_source : c5afc439ba4fe818e4fda15b2756f510cb76d639
This adds a new JS to Java ping-pong; exposes it via Accounts.jsm; and
uses it in response to the fxa-content-server message.
--HG--
extra : commitid : IghQHRrnuUs
extra : rebase_source : 5b255bb6da45abb41f4dfe00c559daaafe83a118
The desired behaviour:
* If we have no account now, and had no account or the same account in
the past -- no message, allow.
* If we have no account now, but had a different account in the past -- prompt.
* If we have an account, and this is the same account -- no message, allow.
* If we have an account, and this is not the same account -- toast and
never allow.
--HG--
extra : commitid : 9vegWtkMoYE
extra : rebase_source : 418f3e616185732c589c1097094260b1f7fbfee0
extra : amend_source : c67d36fa07f7de068998b40389b855c15571ebf3
This ticket does the following things:
* register early. If the first page that Gecko loads is
about:accounts, the channel needs to be in place. If we delay this,
we can and do miss content server messages.
* listen to the following messages:
CAN_LINK_ACCOUNT: 'fxaccounts:can_link_account'
CHANGE_PASSWORD: 'fxaccounts:change_password'
DELETE_ACCOUNT: 'fxaccounts:delete_account'
LOADED: 'fxaccounts:loaded'
LOGIN: 'fxaccounts:login'
The list of messages is from
2a78a14daf/app/scripts/models/auth_brokers/fx-desktop-v2.js (L24)
via
2a78a14daf/app/scripts/models/auth_brokers/fx-fennec-v1.js
This patch implements only LOADED, LOGIN, and CHANGE_PASSWORD. The
messages have the following behaviour:
A LOADED message is ferried to the individual XUL <browser> element it
originated from. In general, WebChannel is a global listener: it does
not matter where a message originates. We want to have fine-grained
control over when an embedding <iframe> is displayed (as opposed to
loaded, in the Gecko sense of loaded). The fxa-content-server
participates in this exchange via the LOADED message; we complete the
loop by specially handling LOADED.
A LOGIN or CHANGE_PASSWORD message either creates a new Android
Account in the Engaged state, or moves an existing Android Account to
the Engaged state. An Android sync is not yet requested -- we'll
arrange that from the Java side.
--HG--
extra : commitid : 1Cw78MNwRHq
extra : rebase_source : eedf8a1bccb5726f4a20d55c1d8496fbfb6c1ca0
This commit does a few things. First, it fixes a typo
(s/ForResponse/ForResult/). It's not clear how this /ever/ worked,
but it did.
Second, it adds an UpdateAccountFromJSON sibling to
CreateAccountFromJSON. It would have been reasonable to have the
create message do double-duty and update an existing account (we have
the latitude to change the meaning since this API is not yet public)
but I generally prefer each consumer to perform the conditional state
check and to act appropriately.
Third, it generalizes the existing Accounts:Exist message to provide
some details (including email and UID) of any existing Firefox
Account. The Accounts.exist() API /is/ public, so I introduce a new
(not yet public) API for this richer information.
--HG--
extra : commitid : 5OcLn2ejQzZ
extra : rebase_source : dca7f1ab0cb101948e9d67db4595b91127f0bfd6
Not sure what to do here so I filed bug 1177901.
--HG--
extra : commitid : BCnmZfSMhyF
extra : rebase_source : dd2c7f167d62883616f522ada485e36966bbc862
Nick Alexander
Petr Marek
Tushar Saini
Mark Finkle
Brendan Dahl
Shih-Chiang Chien
Abhishek Potnis
Sebastian Kaspari
Mohamed Hammoud
Shu-yu Guo
Alex Johnson
alex_johnson
Phil Ringnalda
Carsten "Tomcat" Book
Mike Hommey
Martin Thomson
vivek
Wes Kocher
Anirudh S
Liang-Heng Chen
Mantaroh Yoshinaga
Myk Melez
Dylan Roeh
Margaret Leibovic
Michael Comella