My strawman proposal for Skyline timeframe is very simple: * For (1), load "https://send.firefox.com/?entrypoint=fxa_discoverability_native&utm_source=... * For (2), load "http://send.firefox.com/?email=user@example.com&entrypoint=fxa_discoverability_native&utm_source=... * For (3), don't make any changes, because we're not staffed to do so 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.
Bug 1567403 Comment 1 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
My strawman proposal for Skyline timeframe is very simple: * For (1), load "https://send.firefox.com/?entrypoint=fxa_discoverability_native&utm_source=..." * For (2), load "http://send.firefox.com/?email=user@example.com&entrypoint=fxa_discoverability_native&utm_source=..." * For (3), don't make any changes, because we're not staffed to do so 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.