998051 - Re-architect the FxA Sync login to load directly in a tab, not in an iframe in about:accounts

Status: RESOLVED WONTFIX

(Firefox :: Sync, enhancement, P3)

Description

[Chris Karlof [:ckarlof]]

Overall, I think this will be cleaner, and will also help us avoid problems with the back button. Also related is Firefox's third party cookie policy. If set to "accept third cookies: from visited", this breaks the hosted iframe page in about:accounts, but not if it's loaded at the top level. A recent change in the Fx31 default third-party cookie policy is currently causing problems related to this: Bug 998033.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

This should probably be accomplished by moving much of the code from aboutAccounts.js to a content script that watches for the relevant events on all pages, and reacts to them only if the page is served from https://accounts.firefox.com.

Then we'll need to update any places where we open about:accounts to instead open accounts.firefox.com directly (this can be done while maintaining about:accounts in the location bar, as we do with about:credits). A little complication: we still need to be able to link to the specific entry points somehow (reauth, create account, sign in to existing account, etc.).

Comment 3

[Chris Karlof [:ckarlof]]

Copying from Bug 998937:

Problem: 
A path to the Sync sign up and sign in flow does not exist in a standard web page. It is only accessible via 'about:accounts'. Users can access this flow via the new menu panel, found in the Firefox 29 design. This is not a standard web page and therefore can not be directly linked to from mozilla.org (or any web page). 

Note that 'accounts.firefox.com' is a web page that supports account creation, but does not mention Sync specifically because accounts are used for multiple products. It currently contains no mention of Sync and is not an appropriate flow to send potential and current Sync users through.  


Solution:
The flow that is currently found at 'about:accounts' should also exist in a standard web page so that it can be linked to from Mozilla.org. Possible applications: Snippets, any mozilla.org page mentioning sync, SUMO, Sync marketing pages, Firefox newsletter.

Comment 4

[Ryan Feeley [:rfeeley]]

Just a heads up that there may in future be more than one browser-specific feature that is being enabled when creating an account. For example, WebRTC chat will likely use Firefox Accounts.

Comment 5

[Holly Habstritt Gaal [:Habber]]

(In reply to Ryan Feeley from comment #4)
> Just a heads up that there may in future be more than one browser-specific
> feature that is being enabled when creating an account. For example, WebRTC
> chat will likely use Firefox Accounts.

Good point to mention, Ryan. If a user intends to sign up for Sync, that should be taken into account when sending them into the accounts flow (like it is in about:accounts). Right now 'accounts.firefox.com' does not mention sync and is why we wouldn't send somebody with the intention of signing up for sync through this flow. 

There are 2 ways we could approach this: 
1. All flows could exist at a generic accounts flow URL if we can present conditional steps and content that recognize the users intention and the product they want to sign up/in for. 

2. Or, we can have unique URLs per product sign-in flow that integrates the necessary Account sign-up fields.

Ryan, you've probably thought through this more extensively than me. Thoughts on the best approach?

Comment 6

[Richard Newman [:rnewman]]

(In reply to Holly Habstritt Gaal [:Habber] from comment #5)

> 2. Or, we can have unique URLs per product sign-in flow that integrates the
> necessary Account sign-up fields.

Worth noting that you might be trying to use an FxA with an arbitrary service that we can't possibly have baked into our sign-in flow. Prior art here, alas, is stuff like OAuth.

Comment 7

[Ryan Feeley [:rfeeley]]

Just had a quick chat with Madhava. One of the features we'd like to see for a redone about:accounts is a fallback for when there's no internet connection. We need to reduce instances where native browser chrome presents links to features that are hosted solely on the web. Thoughts?

Comment 8

[Chris Karlof [:ckarlof]]

You can't log in if there is no internet connection. What kind of login experience do you want if there's no internet?

Comment 9

[Chris Karlof [:ckarlof]]

No plans to do this right now. We can re-open if necessary.