40 bytes, text/x-review-board-request
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?
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.
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.
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.
This has all landed in various dependent tickets.
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Component: Firefox Accounts → General
Product: Android Background Services → Firefox for Android
Target Milestone: --- → Firefox 43
You need to log in before you can comment on or make changes to this bug.