1871579 - Chrome profile migration is potentially not importing enough history entries

Status: NEW

(Firefox :: Migration, enhancement, P3)

Description

[Juliana Gaibler [:juliana]]

Hi!

When I import my Google Chrome profile (which I use for personal browsing and some web development) the imported history only goes back eight days.

Gijs pointed out that we have the pref browser.migrate.chrome.history.limit where the imported history entries are limited to 2,000 (as per bug 1340115, to keep the import time low). So I went through the history entries to get a sense of what got imported.

Here are some stats from the imported history (no overlap, 781 items, 40% of imported history):

• Just Google searches alone (416 entries, 20.8% of imported history)
• Browsing and buying on Amazon in a span of 45 minutes* (183 entries, 9% of imported history)
• Going through one photo album on IMDB (50 entries, 2.5% of imported history)
• Reading Vite docs for 10 minutes** (40 entries, 2% of imported history)
• All visits to YouTube (102 items, 5% of imported history)

I would argue my browsing behavior is pretty normal (probably on the high side, and maybe searching a bit too often hehe) but I think its apparent that it just takes a couple of history-polluting sites (i.e. amazon, IMDb, Vite) to eat at the limit which in turn meaningfully reduces the value that the import is supposed to provide.

I made another import attempt by setting browser.migrate.chrome.history.limit to 999999999. The import took longer (before it was less than a second, now it took around 9 seconds on my Mac Studio), which imported 26,779 history entries, going back to late September, probably where the Chrome history ends, as that is not retained for long.

---

I have not looked at our telemetry, but I would wager a guess that maybe with the advent of SSDs the import time is now far lower than it was 7 years ago, so I would suggest increasing the import limit. Maybe telemetry can tell us a good sweet spot, altough I would argue that waiting around 9 seconds is a good trade-off in turn for a more personalized experience.

Speaking of personalized experience: I kind of expected our shortcuts on new-tab to get populated with sites based on my history, or that the address bar would autocomplete an address from my history, but neither of those things happened, which I thought was one of the major draws of importing the history in the first place. Is that on purpose?

---

* 119 of those Amazon entries are just me scrolling through one page, where Amazon constantly updated the query string the further down I scrolled, apparently.
** The problem here is that even though I only visited a couple of pages, the URL fragment got updated every time I scrolled by a headline.

Comment 1

[:Gijs (he/him)]

At my request Julian filed bug 1871582 for the use of history by new tab / the address bar.

(In reply to Julian Gaibler from comment #0)

I have not looked at our telemetry, but I would wager a guess that maybe with the advent of SSDs

People overestimate how many people have SSDs. Fully 25% of users still have their profile on non-SSD disks (client % in the last 3 months).

Your mac studio (unfortunately, in some ways!) is really not representative of most of our userbase.

the import time is now far lower than it was 7 years ago, so I would suggest increasing the import limit. Maybe telemetry can tell us a good sweet spot,

It looks like we don't have good current telemety to know how quickly import completes. Maybe Mike can doublecheck this when he's back.

altough I would argue that waiting around 9 seconds is a good trade-off in turn for a more personalized experience.

Waiting 9 seconds while the browser is completely frozen/unusable with no progress indication doesn't sound acceptable.

Comment 2

[Victoria Wang [:victoria]]

This seems like it could have an impact on retention for new users who notice that the address bar isn't autocompleting how they expect it to. Users who don't notice it might still get the ambient sense that Firefox works less smoothly/intelligently than Chrome.

As a stopgap, could we test out 4,000, 6,000, etc imports on current low-end reference machines, and find something that seems like a reasonable middle ground? A few seconds of waiting isn't necessarily worse than instant, and based on some studies, with appropriate progress indication it can increase the user's trust in a process.

Comment 3

[Mike Conley (:mconley) (:⚙️)]

(In reply to :Gijs (he/him) from comment #1)

It looks like we don't have good current telemety to know how quickly import completes. Maybe Mike can doublecheck this when he's back.

Correct, this probe expired in version 92: https://searchfox.org/mozilla-central/rev/b1a029fadaaabb333d8139f9ec3924a20c0c941f/toolkit/components/telemetry/Histograms.json#8920

We don't have any other existing Telemetry that measures import performance of history.

(In reply to Victoria Wang [:victoria] from comment #2)

This seems like it could have an impact on retention for new users who notice that the address bar isn't autocompleting how they expect it to. Users who don't notice it might still get the ambient sense that Firefox works less smoothly/intelligently than Chrome.

As a stopgap, could we test out 4,000, 6,000, etc imports on current low-end reference machines, and find something that seems like a reasonable middle ground? A few seconds of waiting isn't necessarily worse than instant, and based on some studies, with appropriate progress indication it can increase the user's trust in a process.

I have an alternative proposal: would we consider modifying the migration experience such that the dialog does not need to block until the migration has completed for certain resources?

What I envision is something like this:

1. User has an enormous quantity of history
2. The migration dialog detects this, and instead of reporting that all history has been imported, it reports that history is in the process of being imported, and that the user can continue using the browser while this occurs.
3. The user can dismiss the dialog. In the background, the large quantity of history is being broken up and inserted in Places in batches, letting the event loop breathe.

One of two things will then occur:

1. The migration will complete, and we show the user some indication that this is so - perhaps via a native OS notification?
2. The user will want to quit the browser before the migration can complete. We cannot continue migrating while we're not running, so we might need to warn the user that the import wasn't completed and give them the option of waiting until this occurs before quitting.

Ania, what are your thoughts on that?

Comment 4

[Victoria Wang [:victoria]]

I have an alternative proposal: would we consider modifying the migration experience such that the dialog does not need to block until the migration has completed for certain resources?

Yes, that seems ideal! A message explaining that the import will continue in the background could also help mitigate this similar issue that causes a delay before autocomplete suggestions are ready.