This was not broken on tablet.
The new ShapedButtonFrameLayout class is a duplicate of ShapedButton's LWT
code. I tried an approach that extracted this code out to an external class, to
prevent code duplication and reduce the code size but due to the access rights
on the super classes, it was really messy and, imo, not worth it.
This is a Fennec version of about:accounts, cribbed largely from
Desktop's implementation. This implementation serves two purposes:
One, it allows all fxa-content-server pref handling to remain in
Gecko. Java-side consumers redirect to about:accounts?action=... and
have pref munging and parameter addition (like context=fx_fennec_v1,
etc) handled by about:accounts itself.
Two, it handles network connectivity display and error handling. When
a request is started, we display an animated spinner. We transition
smoothly from the spinner to the iframe display if we can, and if not
we hide any network error and offer to retry. This is more important
in Fennec than it is on Desktop. This approach agrees with Firefox
for iOS.
Some additional notes:
The spinner to iframe transition uses the WebChannel listener to send
LOADED messages to the appropriate XUL <browser> element. It's worth
remembering that Fennec's Gecko is single process, so the <browser> in
question is in the same process. None-the-less, we are close to e10s
safe.
There are four actions: signup/signin/force_reauth, and manage. The
first three try to produce a LOGIN message. The last uses the
fxa-content-server to manage the Account settings. *This is not how
this is arranged on Desktop: Desktop redirects to a new tab, not
wrapped in about:accounts.*
This list is not meant to be exhaustive. There are many ways to get
to the Get Started activity; not all of them are interesting. We're
just trying to capture the significant entrypoints, like firstrun and
preferences.
Pretty straight-forward. It's possible that getStringExtra is not
safe in the face of malicious data; the worst we might expect is a
crash on the Java side; a large memory allocation on the JS side; or
significant URL data transfer. The first is valuable because we'd see
abusers in crash-stats; and the second two are already possible when
opening any URL.
The spinner itself is 60px square, colored like fennec_ui_orange.
The HTML and CSS was hacked out of
https://github.com/lightningtgc/material-refresh, tree
6b1be0046d.
The original code is licensed MIT. I pruned things we don't use,
adjusted the box model for our use, changed the spinner color, and
simplified the CSS.
This just directs to about:accounts?action=manage, which determines
the relevant URL and displays the web content.
Nota bene: about:accounts hasn't landed yet.
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 patch allows you to set MOZ_APP_ANDROID_VERSION_CODE in a branding's configure.sh to specify the exact android:versionCode to use in the final (main) APK. It does *not* modify the android:versionCode used in any other APKs.
This always loads about:accounts with an 'action' query parameter.
This indirection allows Gecko to manage the fxa-content-server pref
independently of Java.
