I'm pretty sure I've heard limi mention this before, but I didn't see a bug on it, so here we are ... We should make it possible to import profile data from Firefox Sync on first run.

Sync right now is optimizes for the synchronization use case and not for backup or migration. The latter ones are quite lossy if you use Sync. There are also UX problems when dealing with just one machine, due to the Sync Key. (When you have multiple machines, we can use the easy setup wizard to transfer the credentials securely.) These aren't insurmountable problems, but they need to be figured out :)

Little amazed we haven't fixed this yet. We're pushing a few things with getting people on the new Sync, feels like this should be one of them. IMO, doesn't matter if Sync is lossy or not for this.

This sounds a little tricky at the current time. Supporting "legacy sync" would be tricky - without access to the old profile (and assuming the user doesn't have a copy of their recovery key), this couldn't work (IIUC). So in reality we'd only be able to support FxA sync. But while many users are still using legacy sync, the UX around this seems problematic - eg, we'd somehow have to make it clear only FxA works and expect the user to know the difference, and handle upset users who didn't know they were on legacy sync and are wondering why their username/password isn't working for them.

Chris More, Matt Noorenberghe, Shane Tomlinson, Ryan Feeley and I met to go over a plan to do this using the sync account creation iframe flow that we are currently using on the /firstrun page. I've attached a spec for changes to the migrator and here are Matt's notes from our meeting: • implemented for a test so it doesn't need to be perfect • css tweaks needed for form layout • links to other page from the form (legal/privacy) need to be handled (probably in the same frame) • change the next button to a skip button (string change!), and hide other buttons for the first step. • webchannel switches button from skip to next and needs to switch state ◦ ideally disable back button on browser choice page after skip ◦ hide "chose what to sync” on server • figure out what happens when opening a link in Firefox while in the middle of migration • hide snippets in verified frame • changed window title (string change) [verdi: we can cut this in the interest of time if necessary] • double-check that webchannel permissions work in subframes of the frame. • Make sure sync webchannel listeners are setup so Sync is properly setup once the browser window opens

:mattn: can you give us an estimate on how long it would take to build a working prototype of this, when (as in period of time), and who could do the work? We could probably do some qualitative testing on it before doing a quan test to understand how it performs. The goal is to determine if this flow has positive benefits and only then should it ride the trains. We want to avoid doing the development, making it code perfect, riding the trains, to later find out users don't respond well to it. We just want to get this work scheduled and just plan toward that. We have considered doing tests like this with bundled add-ons in Firefox that change something, but I don't think that would be an option here.

(In reply to Chris More [:cmore] from comment #6) > :mattn: can you give us an estimate on how long it would take to build a > working prototype of this, when (as in period of time), and who could do the > work? That's hard to answer :) But now that legacy Sync is retired, we'd probably "just" need a web-based login flow, then another page with some nice UX to allow a first-sync to complete. There's no real reason it couldn't be in an addon, but that will add some overheard in terms of time. It's at least a couple of weeks of work I'd guess and everyone seems already over-allocated :/ I hope this is the info you need; please re-ni? if not...

I think a prototype could be made in one week using WebChannel as the logic from the the Firefox side isn't too difficult. You will need a separate estimate from the server side to have the page send some additional WebChannel messages. I wouldn't recommend doing the bulk of the implementation in an extension as it adds more overhead but we talked about having a pref to enable this initial wizard page with a frame via a pref so you can test stuff with FunnelCake.

(In reply to Matthew N. [:MattN] from comment #8) > I think a prototype could be made in one week using WebChannel as the logic > from the the Firefox side isn't too difficult. You will need a separate > estimate from the server side to have the page send some additional > WebChannel messages. IIUC, we could bootstrap the world with a simple email/password form today - but I figured displaying (roughly) about:accounts or firstrun in a dialog might not be much harder and would avoid handling login/account related errors. > I wouldn't recommend doing the bulk of the implementation in an extension as > it adds more overhead but we talked about having a pref to enable this > initial wizard page with a frame via a pref so you can test stuff with > FunnelCake. Yeah, there's certainly a long-tail after the code is done, which is why I was more pessimistic with my estimate ;)

We already have a form that we embed in iframes so I think we just need that page to send some additional events and make sure that the FxA/Sync services that normally listen to those events are running during the migrator.

We want this option to be a sign-in page and not a create an account page as specified in the attachment https://bugzilla.mozilla.org/attachment.cgi?id=8662934 I'll post a new mockup soon.