1161234 - Implement web based Firefox Account sign up/sign in activity

Assignee

Description

•

9 years ago

This is Bug 951304, but on the web instead of native. It's an integrated version of Bug 951306.

This tracks experimenting with embedding accounts.firefox.com in either a web view or a tab rendered with Gecko. I really don't know what the better options is; this ticket is partly the forum to discuss the pros and cons.

Some considerations:

* It's faster to open a Webview, since we don't need to load Gecko. Unclear this matters, since most folks start connecting to Firefox Accounts from within the browser (not from Android Settings, say).
* It's easier to maintain existing the Activity-based flow with a Webview. If we use Gecko, it would be much harder to open a tab, do an Activity-like thing, and then bounce back out to some calling Activity. (This can't be avoided, since the system account manager expects to do this.) That's *really* not how Fennec was designed to work; I expect we'd see a great number of edge cases with the App lifecycle exposed if we pursued this.
* Embedding full-featured sites like accounts.firefox.com in a Webview can be tricky. As we add features (like taking profile pictures) it gets harder and harder to just "use a Webview". We've seen this already embedding on iOS.
* Webviews on iOS and Android are quite similar (at least on modern devices), since they're both Chromium under the hood. Of course, we support Gecko on our accounts page natively.
* Embedding a Webview doesn't allow for maintaining credentials in Firefox itself. We want to do this, for example for Bug 1158869. We could solve this with messaging between chrome and accounts.firefox.com, but that's really not "of the web".
* If we embed a Webview, we have less control over the micro-interactions (how the keyboard works, for example) on the pages. Since all of our users will use Gecko, it's hard to introduce a potentially incompatible system.
* If we open a Gecko tab, we have to consider flows that span multiple tabs, or that can start in one tab and finish in another. In general, I believe this problem is squarely on the fxa-content-server and team, but it's worth recognizing the cost.
* Either way, our self-hosting/custom server story changes. If we work within Gecko, the about:config precedent is set. We'd have to handle custom servers in a custom Webview manually. On the flip side, we're unlikely to support dynamically changing about:config prefs *after* an Android Account is created, and we'd have to ensure the fxa-content-server didn't allow doing things like logging in a second user while a different Android Account exists. Tricky stuff.
* Using a Webview is easy from within the android-sync git repo. If we use Gecko, we'd pretty much have to move big chunks of code into Fennec proper. Just something to be aware of.

Lots and lots of questions.