Closed Bug 1034199 Opened 10 years ago Closed 10 years ago

Avoid a popup for FxA on Desktop

Categories

(Marketplace Graveyard :: Integration, defect, P2)

Product:
Marketplace Graveyard
Component:
Integration
Version:
2014-Q2
Platform:
x86
macOS
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: andy+bugzilla, Unassigned)

References

Details

From an email - try to avoid a popup for Firefox Marketplace, because:

* We want our login to look and behave the same no matter what the service.
* User testing says pop-ups are confusing + freak people out when they see them. * This was a big issue with Persona, and one we’d like to avoid with FxA. 
* Pop-ups make our iterative UI tweaks of FxA much more difficult.
* Pop-ups cause layout bugs like this one: https://www.dropbox.com/s/9hnebik6fiypj80/Screen%20Shot%202014-07-03%20at%2012.45.39%20PM.png
+1 to this. But what would be better visual treatment of presenting this since FxA is a third-party service? Facebook offers pop-ups or modals. Google and Twitter offer pop-ups or redirects. I like Stripe's embedded Checkout flow (visit https://stripe.com/docs/tutorials/checkout and click "Pay with Card").

I heard that FxA requires some redirect in the flow because of OAuth, but I'm not familiar with the details.
If Firefox Accounts ever does support true third party services (i.e. non-Mozilla properties), we will offer a pop-up option.

Google has an incredibly uniform redirect flow for all of their properties (do a Google search for site:accounts.google.com to see just how many) and this is a good fit for us too as it provides a more unified experience. Facebook and Twitter don't offer popup for their own properties, but make it an option for 3rd party sites.

For Mozilla, it's important that we work towards creating a whole that is greater than the sum of our browsers, services and other applications. A sweet, effortless sign-in is the key to this experience.

Chris will chime in and address the reasons these things can't be done in iframes (i.e. iframes can be click-jacked by javascript).
Flags: needinfo?(ckarlof)
> (ryan) If Firefox Accounts ever does support true third party services (i.e. non-Mozilla properties), we will offer a pop-up option.

> (christopher) I heard that FxA requires some redirect in the flow because of OAuth, but I'm not familiar with the details.

There's nothing we as FxA can do to prevent *any* relier from using a pop up UX for a delegated login flow. They basically do the redirect flow in a new window and then close it when it's done.

A pop up doesn't necessarily have any security concerns, but has UX tradeoffs, as Ryan has mentioned.

> Chris will chime in and address the reasons these things can't be done in iframes (i.e. iframes can be click-jacked by javascript).

iframes definitely have click jacking issues. We could potentially address this (with some complexity) with a dynamically set X-Frame-Options header with ALLOW-FROM for the site if it's on a whitelist. Regardless, an iframe approach still has some of drawbacks above. It makes it more challenging for us to make layout tweaks to our sign in screens without creating regression risk on our reliers.

A pure redirect approach has a nicer separation of concerns. A much larger popup window could address some of the layout issues, but other issues remain.

Andy, do you guys have fundamental objections to a redirect approach or is the main issue that you don't currently have sufficient mechanisms to serialize and save (and resume) the user flow during authentication? I understand that work may be significant, but I just want to get a lay of the land.
Flags: needinfo?(ckarlof)
Bill can you weigh in here?
Flags: needinfo?(wmaggs)
> Andy, do you guys have fundamental objections to a redirect approach or is
> the main issue that you don't currently have sufficient mechanisms to
> serialize and save (and resume) the user flow during authentication? I
> understand that work may be significant, but I just want to get a lay of the
> land.

None at all, this is just the most expedient result to getting it working right now.
Thanks Andy! I understand completely.
Priority: -- → P2
(In reply to Andy McKay [:andym] from comment #5)
> > Andy, do you guys have fundamental objections to a redirect approach or is
> > the main issue that you don't currently have sufficient mechanisms to
> > serialize and save (and resume) the user flow during authentication? I
> > understand that work may be significant, but I just want to get a lay of the
> > land.
> 
> None at all, this is just the most expedient result to getting it working
> right now.

Fireplace (the Marketplace front-end UI) has no ability to handle redirects and we should avoid them at any cost. If that's an interim solution, let's do it.

But on mobile especially redirects are not a good experience at all. Fireplace is a single-page app. This means clicking on any internal link takes you to a new page, which is actually just a new template rendered with JavaScript.

Any redirect to another page, any synchronous page load, breaks the flow. I assume after successful login, FxA redirects us back to the Marketplace. Also, what happens if the login is unsuccessful, would FxA be gracefully handle that and redirect back to the Marketplace?

Forgive me if I'm totally misunderstanding the redirect flow. After the redirect, we now have to do another synchronous page load, causing all the HTML, JS, and CSS to be reloaded. This is very unfortunate. This is especially painful when we would cause a login during a purchase flow. We would have to remember the page state (which could be 5 pages of "More" results on search page, for example), the scroll position, everything.

Also, what happens when the user signs in, is redirected back to the Marketplace, and presses the back button? Today, the user's history is unaffected by signing in.

Why can't we have an <iframe>'d solution à la Stripe Checkout where we full-screen an <iframe> that lives on the FxA domain? That's typically how this is done these days.

This has immense UX implications that downright scare me.
To illustrate the above in a couple of scenarios:

1) You're browsing the Marketplace.  You scroll to the bottom of a list, and click "more" - you continue browsing and continue to click more - at some point you click to buy an app.  You must be logged in to proceed.  Moving to a 3rd party site will lose your state - we'll forget how far you scrolled and what order those results were in (depending on sort, it could change).

2) The Freemium model:  We want people to play Game X as quickly as possible so we put a Play button on the front page and we have thousands of people playing it.  One of the options in the game is to buy some armor from one of the in-game vendors for 99 cents.  When you click the vendor the option to buy appears, but when you click the button you must log in.  If we load a 3rd party site here we can't redirect back to that spot in Game X easily and you lose your connections (e.g., your friends will see a notification that you went offline).

Other questions/concerns:

* History (back button) is broken (no chrome-level back button in Marketplace, so all history before the login is lost)
* Assets are re-downloaded after the redirect (albeit, cached)
* How are unsuccessful logins handled?
* How are cancellations handled?

It sounds like Tauni is scheduling an off-cycle meeting for us to chat about these scenarios.  The current implementation (a popup) is usable for testing so we're not blocking anything while we talk about other options.
:cvan, thanks for sharing your concerns. I think your understanding of the redirect flow is correct.

This is a tricky one. We definitely want to create a Firefox Accounts that meets the requirements of all relying Mozilla services, which of course includes Marketplace. I think the way forward here is our UX guys to get a broader understanding of the requirements, so they and I can work with your team and Maureen to figure out an experience that works for everyone. I've already spoken to Wil, and he's taken the action on that.

Here's a little bit more information on requirements from the FxA perspective:

The signin/signup experience needs to be as consistent as possible across our properties, sending a strong signal to the user that the FxA they created on Marketplace is the same account they use to log into Find My Device. We're going to get into an untenable situation if every relying Mozilla service independently integrates with FxA in a way of their own choosing. 

The FxA flows also have significant complexity, and we need screen real estate to execute them properly and have the flexibility to change them in the future. We have a sign in flow, a sign up flow with email confirmation, links to ToS and PN, a COPPA UI, and a password reset flow which also requires checking email. In future, we plan on adding an avatar selection process and other profile customizations to the signup flow, two factor authentication, and an account chooser for using previously authenticated accounts at a relier. 

I've watched many users go through signup and signin flows with email verification (FxA and otherwise), and I never ceased to be amazed with all the different ways that users do those flows. Users check their email in many different ways. Some will open gmail in the tab with your application and some will copy and paste the link into the tab with your application. Some users will close your application's tab, or minimize or close the entire browser before they check their email. A email check/link click could happen in either a signup and or signin flow (e.g., password reset), and IMO it's generally dangerous to take the user into a sign in or sign up flow without serializing the application's state as much as reasonably possible beforehand, regardless of how the login is implemented.  

We can explore iframe approaches, but I've come to dislike full screen iframed pages where the URL bar betrays what page is actually loaded. For example, viewing the ToS could take the user on a wild goose chase, which if the ToS includes a link back to the Marketplace ToS, could hilariously load Marketplace in an iframe contained on Marketplace. Simpler, more constrained UIs like Stripe are a nice application of lightboxed iframes because it's harder for the user to get off-track.

Allowing the iframing of login screens would also require us to address clickjacking attacks (framing is currently not allowed via X-Frame-Options). X-Frame-Options ALLOW-FROM is not really sufficient here and isn't supported cross-browser. We can probably craft a solution based on postMessage, but it's complexity and work. 

We could try to answer some of the UX unknowns via user testing. John and Ryan use usertesting.com. We could prototype a couple of options and see which ones users have the easiest time with.
John, Ryan, and I indeed need to consider all the use cases previously cited, and ones like Wil talks about above. Many are more important in a mobile use context, where state is even more important. We can at least get those straight, and then figure out what technical solution fits.
Bill has just pointed out to me that we're probably speaking past each other!

Are you guys primarily talking about FxA + Marketplace on older FxOS devices or on Desktop? I think we can work together to figure out some creative solutions for legacy FxOS devices, but we'll need to converge on that soon because we haven't considered that much outside of specific requests like: https://github.com/mozilla/fxa-content-server/issues/1271
The original request from UX was for Desktop, but I think we should have the same flow for all devices.

I was going to suggest that there would be two levels of caring about the state:
1) places where its an edge case and we don't care about the state, eg: search
2) places where we think the state is important and is something we have to preserve, eg: payments

Then I was going to hang bugs off of this one fixing up state in those areas and working through those edge cases to make sure they all work and then we can flip from a popup to doing redirects. Those areas we have identified so far are:
* writing a review
* my apps
* doing a purchase (we have to do this for android anyway)

There are likely going to be others but I don't think we need to in state everywhere for everything unless we really think that's of value.
I object 100% to comment 12. (And breaking the back button and eliminating the user's history, no matter if payments involved, is far from an edge case.) This is going to cause an extraordinary number of bugs and headaches.

If we were building synchronous web pages, I'd say, let's add the redirect and be done with it. But with our apps initiative, and especially with Firefox OS, if we're telling developers to build *apps* (i.e., single-page apps), then we can't expect all the future adopters of Firefox Accounts to have to maintain the state of their apps. It's just not something that developers do, and I'm not sure why they would bend over backwards to do this for our auth system when they can use any of the readily available ones (e.g., Facebook Login, Twitter, Google+, Authy).
Flags: needinfo?(wmaggs)
Could at the very least we make the FxA auth screen popup-friendly like the Persona popup currently is? And on Firefox OS, could we use the Trusted UI like we are today for Persona?
(In reply to Christopher Van Wiemeersch [:cvan] from comment #13)
 
> If we were building synchronous web pages, I'd say, let's add the redirect
> and be done with it. But with our apps initiative, and especially with
> Firefox OS, if we're telling developers to build *apps* (i.e., single-page
> apps), then we can't expect all the future adopters of Firefox Accounts to
> have to maintain the state of their apps. It's just not something that
> developers do, and I'm not sure why they would bend over backwards to do
> this for our auth system when they can use any of the readily available ones
> (e.g., Facebook Login, Twitter, Google+, Authy).

When we open FxA on FxOS to third party developers, the current plan is to use the native DOM APIs and UI to handle authentication. However, we have no timeline to open FxA on FxOS to third party devs at this time.
> Could at the very least we make the FxA auth screen popup-friendly like the Persona popup currently is? And on Firefox OS, could we use the Trusted UI like we are today for Persona?

I assume you're talking about the "backport FxA for Marketplace" on 1.3 case here. I understand this is an important use case.

Can you tell me more about what it means to be "popup-friendly"? Are you asking for a postMessage interface between the opener and the opened window?
(In reply to Chris Karlof [:ckarlof] from comment #16)
> I assume you're talking about the "backport FxA for Marketplace" on 1.3 case
> here. I understand this is an important use case.

I don't think we should think about backport of 1.3 in isolation. The Marketplace biggest users are likely to be Android and Desktop as we launch those this quarter. There's native FxA on Firefox 2.0 then everyone else, Android, Desktop, Firefox OS < 2.0 and so on.
> I don't think we should think about backport of 1.3 in isolation.

I agree. I am still getting my head around relative priorities, timelines, and limitations. I don't think we're going to have a solution that has the same UX everywhere (iframe vs native vs redirect vs popup), but a library can at least hide some of the integration complexity.
(In reply to Andy McKay [:andym] from comment #17)
> (In reply to Chris Karlof [:ckarlof] from comment #16)
> > I assume you're talking about the "backport FxA for Marketplace" on 1.3 case
> > here. I understand this is an important use case.
> 
> I don't think we should think about backport of 1.3 in isolation. The
> Marketplace biggest users are likely to be Android and Desktop as we launch
> those this quarter. There's native FxA on Firefox 2.0 then everyone else,
> Android, Desktop, Firefox OS < 2.0 and so on.

Hey Andy, what do you mean by saying that biggest users will be Desktop and Android? Much as I would like that to be true, latest info I see is that Marketplace activity on Android is dwindling, and the share of new and unique users relative to FxOS is much lower as shipments of FxOS devices have finally taken off, according to GA: 

https://www.google.com/analytics/web/?authuser=1#report/visitors-browser/a36116321w65336229p67582515/%3F_u.date00%3D20140613%26_u.date01%3D20140713%26explorer-segmentExplorer.segmentId%3Danalytics.operatingSystem%26explorer-table.plotKeys%3D[]/

Conversion rate on app installs down from 12% to less than 5% and successful app installs down to 5% of the total apps we're installing. Bounce rate, duration of visit, all are down.  Basically, on Android users come to Marketplace, look around, and leave without installing apps, much less logging in. Desktop behavior could be different with more promotion or a desktop games destination, but I still think FxOS is the primary use case for FxA on Marketplace.
Here's some thoughts about putting the FxA flow in an iframe:

https://github.com/mozilla/fxa-content-server/issues/1386
> > I don't think we should think about backport of 1.3 in isolation. The
> > Marketplace biggest users are likely to be Android and Desktop as we launch
> > those this quarter. There's native FxA on Firefox 2.0 then everyone else,
> > Android, Desktop, Firefox OS < 2.0 and so on.
> 
> Hey Andy, what do you mean by saying that biggest users will be Desktop and
> Android?

You'll notice I used the words "are likely to be". I'm hoping this will be the case.
Chatting to ckarlof, there is going to be a popup flow in FxA. That's pretty awesome of them. So I'll close this and reopen with a new "let's use the awesome popup choice" bug as soon as that is ready to go.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
> Chatting to ckarlof, there is going to be a popup flow in FxA.

It won't be a "popup" in the conventional sense (i.e., the notion of a popup in the phrase "popup blocker", but an iframe overlay on top of the relier's page.
You need to log in before you can comment on or make changes to this bug.