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.
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.
This always loads about:accounts with an 'action' query parameter.
This indirection allows Gecko to manage the fxa-content-server pref
independently of Java.
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.
There are enough Accounts: messages to separate them from BrowserApp,
and the list is only growing.
This has also the small advantage of removing some non-native event
listeners.
This patch stops referring to package/class objects to identify
Android components directly and instead launches through action intent
filters. The intent filters are scoped to the package, but not marked
as private or as requiring a permission. A malicious package could
inject itself into an account flow, but I don't think there's much
advantage: the only time a secret is passed between activities is when
the native sign up (CreateAccount) and sign in (SignIn) activities
link between themselves, and in this instance I didn't route through
the action intent filters. (This is entirely native -- there's no web
analog -- so I didn't use the indirection.)
I tried to use the `?android:attr/...` method listed in the nearby comments but
kept receiving a "ResourceNotFound" exception. I wonder if this is related to
the way we inherit and then override the themes.
This patch reintroduced changes behind a nightly flag removed by:
1161638: Remove the chrome at the bottom of the screen in the Tabs Tray
1164723: Inherit from Tablet UI on Mobile UI (aka compact tabs)
1193745: Implement the tablet tabs tray grid view on mobile
I've also done a bit of work to allow the chrome to sit at the correct Y location in landscape on mobile devices when the tabs panel is shown to account for bug 1193374 which adjusts the aspect ratio of the tabs panel thumnbnails and didn't need to be hidden behind a nightly flag. Tablets remain unaffected by this change.
