Closed Bug 1567403 Opened 5 years ago Closed 5 years ago

Create FxA Toolbar landing page for Firefox Send

Categories

(Firefox :: Firefox Accounts, enhancement, P1)

Product:
Firefox
Component:
Firefox Accounts
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: rfkelly, Assigned: dcoates)

References

Details

(Whiteboard: [fxa] [skyline])

In Bug 1562006, we will be adding a item to the Firefox Account Toolbar menu to help users discover Firefox Send. The full UI spec is in Invision here, but the relevant parts for integrating with Send are:

  • If the user is not signed in to Firefox, they will see a little description of the Firefox Send service and a button saying "Launch Send".
  • If the user is signed in to Firefox, they will see a little description of the Firefox Send service and a button saying "Continue as user@example.com".

These buttons will open Firefox Send in a new tab, and this bug is about figuring out the details of exactly how it will be opened. We need to:

  1. Agree on the precise URL that will be opened by the "Launch Send" button, including any metrics or other tracking parameters.
  2. Agree on the precise URL that will be opened by the "Continue as user@example.com" button, including how to pass in the intended identity, and any metrics or other tracking parameters.
  3. Optionally, design and build a customize experience to help users through this flow more smoothly.

Danny, I know you're flat-out with non-Send-related things, but I'm adding you to the bug in case you can help out with a bit of advice, and to give you the option to veto anything that sounds terrible. Please redirect as appropriate.

My strawman proposal for Skyline timeframe is very simple:

We should look at prior art elsewhere in the browser to determine appropriate values for utm_* parameters.

This will let us track basic click-through metrics for the flow, but users will not get a very convenient signin experience. Even if they're already signed in to the browser, they will land on the generic Send welcome page, and have to find and click on "sign in" in the top-right corner in order to actually get signed in.

Once that initial experience is ready, we can consider having send.firefox.com detect the presence of the email query parameter and provide a smoother onboarding experience, on the reasonable assumption that the user is signed in to their browser and ready to authenticate to the server. See Bug 1562006 Comment 8 for some notes on how the website might like to behave in this case.

Danny, does this seem reasonable? Or would you prefer to have the signed-in case load a special-purpose URL, such as https://send.firefox.com/signin or similar?

Shane, are you happy with us just including the email in the URL like this? An alternative could be to have the browser generate an id_token and send that as an id_token_hint parameter, with the intention that the site can use it to complete a prompt=none signin flow. But that's significantly more complexity in the short term.

Flags: needinfo?(stomlinson)
Flags: needinfo?(dcoates)

(In reply to Ryan Kelly [:rfkelly] from comment #1)

Shane, are you happy with us just including the email in the URL like this? An alternative could be to have the browser generate an id_token and send that as an id_token_hint parameter, with the intention that the site can use it to complete a prompt=none signin flow. But that's significantly more complexity in the short term.

I just sent the email before reading this saying I think for prompt=none, we should not require an id_token_hint for just this case. I think that passing an email and having the client_id on an authorized list of RPs allowed to use prompt=none w/o an id_token_hint would be sufficient.

Flags: needinfo?(stomlinson)

One thing about the URLs, if the intention is to have to user sign in, I'd have a separate path rather than the base indicating "hey, start the OAuth login flow".

One thing about the URLs, if the intention is to have to user sign in, I'd have a separate path

I'm leaning this way as well, if we can get one shipped - even if it doesn't do anything clever right now, it would buy us a bit of optionality for the future.

LGTM. I agree that we should have a new route for (2) and if we can use prompt=none somehow it should be pretty seamless in most cases.

Flags: needinfo?(dcoates)

and if we can use prompt=none somehow it should be pretty seamless in most cases.

It occurs to me that the prompt=none flow won't really work for Send; it uses Scoped Keys so the user will always have to enter their password to unlock the keys.

It would be neat if we could get key material out of the signed-in browser rather than forcing the user to re-enter their password, but that's not likely in the short-term and is something we'd have to think very carefully about from a security perspective.

Mirroring Bug 1567405 Comment 6, how about something like:

This could be a dedicated page on Send that inspects the query params and the local login state and then does the right thing, such as:

  • If the user already has a login session on send.firefox.com, and matches the specified email parameter, then just get started using Send!
  • If the user does not have a login session on send.firefox.com, go straight to something like the current "sign in" splash screen, where it tells them about the benefits of Send and gives them a button to proceed with the login
    • If email was specified in the URL, pre-fill this value in the sign-in form.

We can start off with a really simple version of that URL and iteratively improve it without having to land changes in Firefox.

Eventually, we can teach Firefox and accounts.firefox.com how to cooperate to perform a prompt=none flow with scoped keys, and the user would just start getting a seamless signin experience without having to make any further changes in Send.

Danny, what would it take to land a simple placeholder route for /fxa-onboarding [1] that didn't do anything clever, but just worked as though you'd landed on https://send.firefox.com? If we can ship that and land code in Firefox to load it, then we've got plenty of time before skyline release to iterate the rest of the experience in web content.

[1] Or whatever name makes sense within the URL scheme of Send, I just made that one up...

Flags: needinfo?(dcoates)

/login done ;)

https://github.com/mozilla/send/commit/58191975b9b844610217dee410b7d5ae2051e6ba

We don't have a regularly scheduled deployment right now so let me know when you'd like it deployed.

Flags: needinfo?(dcoates)

Awesome, thank you! :-)

Please go ahead and deploy whenever you're ready, I expect we'll be in a position to link out to it from Desktop code fairly soon.

To summarize, the final URL to load should be:

It will be safe to load this without specifying an email param when the user is not signed in to sync. Vijay, does this work for you?

Flags: needinfo?(vbudhram)

does this work for you?

These changes seem reasonable to me. I've have a patch for this over in https://phabricator.services.mozilla.com/D39230. For utm_source the prior examples use Services.appinfo.name.toLowerCase(), so it would look like this:

Not signed in

Signed in

Flags: needinfo?(vbudhram)
Whiteboard: [fxa]

ni? :dcoates for deployment of the new URL

Flags: needinfo?(dcoates)
Whiteboard: [fxa] → [fxa] [skyline]
Assignee: nobody → dcoates
Priority: -- → P1

this is now live in production with v3.0.14

Flags: needinfo?(dcoates)

Thank you! Tested and seems to work in current nightly. (It doesn't actually sign me in of course, but the page loads and lets me use Send as expected).

Let's close this, and we can follow up with issues in the Send repo if and when we want to provide a more nuanced experience from this landing page.

Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.