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
