1271766 - Implement a way of determining which browser to import data from for auto-importing data on startup

Status: RESOLVED FIXED

(Firefox :: Migration, defect, P2)

Description

[:Gijs (he/him)]

We could potentially use:

- the default browser if it isn't us (doesn't work if it's us)
- rely on the existing ordering that is in use in the migrator dialog
- actually determine which browsers have data available and migrate from the browser that has the most (potentially ignoring things like cookies or history, see e.g. bug 1226036 - if so, what should be ignored?)

Alternatively, we could import data from several browsers if we find it in there.

Verdi, do you have initial thoughts about what you would prefer?

Comment 1

[:Gijs (he/him)]

Clarifying the summary a bit to be less technical.

Comment 2

[Verdi [:verdi] Best to slack me]

(In reply to :Gijs Kruitbosch from comment #0)
> Verdi, do you have initial thoughts about what you would prefer?

My initial thought was to use default browser and if the default browser just has the default data set, we should skip it. On second thought though, any browser is likely to have at least something more then the default data set (unless you never used it or killed your profile) so something like a minimum threshold of data (Bug 1226036 comment 1) would also be needed.

If we're the default browser or if there is an existing profile, we don't show the migrator so I don't think that's a concern.

Now if the default browser doesn't have anything to import we could either, look for another browser with some data or just start with a default set (e.g. Alexa top sites). Here I think the answer depends. If there is only one browser with data then we could import that. If there are two or more browsers with data or two or more Chrome profiles then we should probably skip this and go with a default set. My plan is to surface the "Import data from another browser" command on the new tab page for this case.

Comment 3

[:Gijs (he/him)]

(In reply to Verdi [:verdi] from comment #2)
> (In reply to :Gijs Kruitbosch from comment #0)
> > Verdi, do you have initial thoughts about what you would prefer?
> 
> My initial thought was to use default browser and if the default browser
> just has the default data set, we should skip it.

Note that the default data set changes between versions etc. and, at least for IE, is locale-dependent, so this is pretty hard to detect...

> On second thought though,
> any browser is likely to have at least something more then the default data
> set (unless you never used it or killed your profile) so something like a
> minimum threshold of data (Bug 1226036 comment 1) would also be needed.

OK, this makes sense.

> If we're the default browser or if there is an existing profile, we don't
> show the migrator so I don't think that's a concern.

Is that true? We don't show the migrator if you marked Firefox the default browser in the installer (which is the default, I think?), even if you have no profile data? That seems... surprising.

> Now if the default browser doesn't have anything to import we could either,
> look for another browser with some data or just start with a default set
> (e.g. Alexa top sites). Here I think the answer depends. If there is only
> one browser with data then we could import that. If there are two or more
> browsers with data or two or more Chrome profiles then we should probably
> skip this and go with a default set.

OK. How important do we think this default set is? As in, should we tackle it as part of the migrator push or as part of e.g. bug 1211726 (which envisions something slightly different) ? We already have a set of default bookmarks (that could probably do with some love) - it's not clear to me how important adding some kind of "migrated default set" is, and how that would work e.g. with undoing the migration. It seems like a separate issue, maybe? Also something that we could do on top of or as a basis under the migrated data, so that migrating a relatively clean profile doesn't get you a worse experience than starting with "nothing", so to speak?

> My plan is to surface the "Import data
> from another browser" command on the new tab page for this case.

OK, I wasn't aware of this. It could probably do with its own bug (potentially gated on improving quality of migration before we show it to that many users). Can you file one, especially if you have designs or more specific ideas already?

Comment 4

[Verdi [:verdi] Best to slack me]

(In reply to :Gijs Kruitbosch from comment #3)
> 
> > If we're the default browser or if there is an existing profile, we don't
> > show the migrator so I don't think that's a concern.
> 
> Is that true? We don't show the migrator if you marked Firefox the default
> browser in the installer (which is the default, I think?), even if you have
> no profile data? That seems... surprising.

Sorry, I was thinking of the paveover install flow. You're right. I've filed Bug 1272162 to remove that opt-out checkbox. Should that bug block this one?

> 
> > Now if the default browser doesn't have anything to import we could either,
> > look for another browser with some data or just start with a default set
> > (e.g. Alexa top sites). Here I think the answer depends. If there is only
> > one browser with data then we could import that. If there are two or more
> > browsers with data or two or more Chrome profiles then we should probably
> > skip this and go with a default set.
> 
> OK. How important do we think this default set is? 

I think it's pretty important. I think there will be enough cases where we can't import that we'll want to make sure the no data experience is good.

> As in, should we tackle
> it as part of the migrator push or as part of e.g. bug 1211726 (which
> envisions something slightly different) ? We already have a set of default
> bookmarks (that could probably do with some love) - it's not clear to me how
> important adding some kind of "migrated default set" is, and how that would
> work e.g. with undoing the migration. It seems like a separate issue, maybe?
> Also something that we could do on top of or as a basis under the migrated
> data, so that migrating a relatively clean profile doesn't get you a worse
> experience than starting with "nothing", so to speak?

Sounds like there are many ways to approach this; not sure if this could be handled by bug 1211726. As far as how this would work with the import I was thinking something simple:
Firefox has a set of default top sites (probably nice if these show up in awesome bar results too). If we auto-import data from another browser we should prioritize those over the default top sites. If you get rid of the auto-imported stuff you're left with the default top sites again. 

> 
> > My plan is to surface the "Import data
> > from another browser" command on the new tab page for this case.
> 
> OK, I wasn't aware of this. It could probably do with its own bug
> (potentially gated on improving quality of migration before we show it to
> that many users). Can you file one, especially if you have designs or more
> specific ideas already?

Ok I'll file a bug for that. Are there issues to be resolved with migration quality that we need to fix as part of this project?

Comment 5

[:Gijs (he/him)]

(In reply to Verdi [:verdi] from comment #4)
> (In reply to :Gijs Kruitbosch from comment #3)
> > 
> > > If we're the default browser or if there is an existing profile, we don't
> > > show the migrator so I don't think that's a concern.
> > 
> > Is that true? We don't show the migrator if you marked Firefox the default
> > browser in the installer (which is the default, I think?), even if you have
> > no profile data? That seems... surprising.
> 
> Sorry, I was thinking of the paveover install flow. You're right. I've filed
> Bug 1272162 to remove that opt-out checkbox. Should that bug block this one?

If we're OK with just examining the existing data and determining which to use for importing using some other mechanism than "which browser is the default" (such as, which browser has recent/more data), I don't think so. Alternatively, if you really really want to use the default browser over such a heuristic, we could fix it first. Depends what you prefer. AIUI there are still doubts about how much being the default gets us, and so not doing that in the installer seems like a net loss. OTOH, the OSes where we can do that (win7 and below) are going to be fewer and fewer, so maybe we don't care?

> > > Now if the default browser doesn't have anything to import we could either,
> > > look for another browser with some data or just start with a default set
> > > (e.g. Alexa top sites). Here I think the answer depends. If there is only
> > > one browser with data then we could import that. If there are two or more
> > > browsers with data or two or more Chrome profiles then we should probably
> > > skip this and go with a default set.
> > 
> > OK. How important do we think this default set is? 
> 
> I think it's pretty important. I think there will be enough cases where we
> can't import that we'll want to make sure the no data experience is good.

Sure, but the "no data" experience is already what it is right now. It doesn't seem like it needs to block the changes to the migrator - if there is no data to migrate, the experience will be no worse (arguably better) than it is today. Insofar as the experience is "not good", we're not making it any worse, and the scope of this bug is already... significant.

> Firefox has a set of default top sites (probably nice if these show up in
> awesome bar results too).

What are "top sites" ? History entries? Bookmarks? Just tiles on the new tab page? Something else? This is a computer, there's no magic. :-)

> If we auto-import data from another browser we
> should prioritize those over the default top sites.

Prioritize where and/or in what way? Should the default set not show up at all as history? Something else?

> If you get rid of the
> auto-imported stuff you're left with the default top sites again.

This is likely hard, depending on your answers above, especially if the user does it after 10 days / a month / "later". Also, should the user be able to get rid of these sites? I know I find it really annoying that fennec autocompletes "x" to "xunlei.com" (still no idea what it is, but I remember it because I've seen it so often!) when I always want xkcd.com, and I would have loved a way to get rid of it. Maybe I'm weird? :-)

Based on that and my argument earlier about the "no data" scenario not being something that we *need* to address as part of this push, I'd prefer to punt on this for v1/v0.1. Let's fix the migration stuff, then we can worry about the "no data" thing.

> Are there issues to be resolved with migration
> quality that we need to fix as part of this project?

This is an open question. :-)

There are a lot of issues with migration quality. The question is how badly we think they need resolving. We can't import 'real' history from Edge, because the data is not available to us (I don't think there's a real solution to this at this time.). Chrome imports sometimes break if you have a lot of data. Safari I think is not-always-working since a version or two (I haven't investigated). There's probably other issues. We have telemetry data on migration errors, but I've not had cycles to dive into it too much.

Again, because we're basically just plonking what used to be a manual process into an automated one, I'm not sure we need to do much about this, except perhaps if imports are exceedingly slow. Does that make sense?

Comment 6

[:Gijs (he/him)]

Per discussion with verdi and dolske, going with the default browser for now, and we can adjust based on telemetry data.

Getting a better 'default set' if we don't migrate anything can be dealt with separately.