Implement web based Firefox Account sign up/sign in activity

RESOLVED FIXED in Firefox 43

Status

()

defect
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: nalexander, Assigned: nalexander)

Tracking

(Blocks 1 bug)

unspecified
Firefox 43
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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.
rnewman: you have a much higher level view of risk than I do.  Could you opine on risks and technical considerations I have neglected?
Flags: needinfo?(rnewman)
I agree that using a Fennec tab for this would introduce a large amount of uncertainty.

Not only do we not have a good way to 'return' values and bounce around activities, but we also don't currently impose much control over the interaction. Do we want users bookmarking? Opening links in a new tab? Switching to a new tab and getting distracted half-way through the login process? What if you're in Guest Mode at the time?!

There's the possibility of issues due to interactions with add-ons — we've seen these problems before on desktop, particularly around captchas going missing.

As you note, this also adds a significant amount of lifecycle danger: Bug 964883.

I don't know if there is a path forward that will address those issues within a reasonable timeframe and amount of effort.


So I can imagine two ways forward:

1. Doing the engineering work to allow for a modal Gecko view (not necessarily GeckoView) that shares a single instance of Gecko and your main profile (presumably with an independent top-level window). This doesn't solve all of the issues, but it does fix many of the interaction and activity problems, and handily glosses over some things like password manager access. Arguably this is the best long-term approach.

2. Using the system webview in an entirely separate activity. We have experience doing this several times (FxA help, Search Activity). This gives us the most control over scope and risk. Some of the issues around credential management are understood (e.g., Bug 946857).


I might suggest doing these two things in parallel, shipping the second. Embedding Gecko itself with multiple windows and views is a can we continue to kick down the road, and it'd be nice to do better in time.
Flags: needinfo?(rnewman)
Depends on: 1174458
Bug 1161234 - Part 1: Add "CreateFirefoxAccountFromJSON" message. r?rnewman

We will probably grow a helper module for handling these
account-related messages, but this is enough to develop an
about:accounts style add-on.
Attachment #8622004 - Flags: review?(rnewman)
(In reply to Nick Alexander :nalexander from comment #3)
> Created attachment 8622004 [details]
> MozReview Request: Bug 1161234 - Part 1: Add "CreateFirefoxAccountFromJSON"
> message. r?rnewman
> 
> Bug 1161234 - Part 1: Add "CreateFirefoxAccountFromJSON" message. r?rnewman
> 
> We will probably grow a helper module for handling these
> account-related messages, but this is enough to develop an
> about:accounts style add-on.

Just a little hackery to move this forward.  I'd like to land something hacky like this to unblock my add-on experimentation.
Assignee: nobody → nalexander
Status: NEW → ASSIGNED
https://reviewboard.mozilla.org/r/11101/#review10011

::: mobile/android/base/BrowserApp.java:1687
(Diff revision 1)
> +                        this.mProfile.getName(),

this.getProfile().getName()
Attachment #8622004 - Flags: review?(rnewman) → review+
Comment on attachment 8622004 [details]
MozReview Request: Bug 1161234 - Part 1: Add "CreateFirefoxAccountFromJSON" message. r?rnewman

https://reviewboard.mozilla.org/r/11103/#review10013

Ship It!
Pushed a pre, with rnewman's comment addressed.
Keywords: leave-open
Blocks: 1179949
Blocks: 1179978
url:        https://hg.mozilla.org/integration/fx-team/rev/2822f5313df52dad17b396a3528843aa1d5c7965
changeset:  2822f5313df52dad17b396a3528843aa1d5c7965
user:       Nick Alexander <nalexander@mozilla.com>
date:       Wed Jul 08 13:46:07 2015 -0700
description:
Bug 1161234 - Part 2: Accept non-default auth, token, and profile endpoints. r=me

This allows us to create accounts that Sync against non-production
endpoints from JavaScript.  In future we will include oauth and
eventually content server endpoints in these messages.
No longer blocks: 1179949
No longer blocks: 1179978
Depends on: 1191064
Blocks: 1191067
Depends on: 1191068
Bug 1191067 has become this ticket.
No longer blocks: 1191067
Depends on: 1191067
No longer depends on: 1191068
This has all landed in various dependent tickets.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Keywords: leave-open
Resolution: --- → FIXED
Component: Firefox Accounts → General
Product: Android Background Services → Firefox for Android
Target Milestone: --- → Firefox 43
Blocks: 1229216
You need to log in before you can comment on or make changes to this bug.