User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100919 Firefox/4.0b7pre Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b7pre) Gecko/20100919 Firefox/4.0b7pre When a 2nd (or more) machine with a new profile has sync configured the frecency values are synced across but *not* the adaptive values. This means if on your 1st or primary machine you were used to typing g and have gmail be the first entry in the awesome bar list, you would expect to be able to do the same on your 2nd machine. However as adaptive values aren't synced you just get a selection of sites containing g. More discussion on this subject was in d.a.f. (see url) and I am filing this as a result of that discussion Reproducible: Always Steps to Reproduce: 1. On a primary machine with sync configured find a site that always is returned first when a single letter is typed in awesome bar , (e.g. g for gmail). 2. Create a new profile 3. Configure sync with your normal sync credentials, option to replace all data on this computer with sync data 4. Wait until initial sync has completed by looking at about:sync-log 5. In the awesomebar type g (or whatever letter you used in 1.). Actual Results: Random selection of sites in the awesomebar containing you letter (g) Expected Results: The same site is 1st in the list as on the primary machine This is an enhancement request, it seems we currently aren't using the full power of sync + awesomebar. There may be issues around merging adaptive values from multiple machines which means this will never work as outlined above. So if it is WONFIX so be it.

We should be able to sync this data as an additional anno to history items, as we do with tags for bookmarks. Needs beta exposure to catch any niggling cases, but this is not blocking a specific beta.

We could add another property to history records: inputs: [[input, use_count], [input, use_count], ...] or more verbose: inputs: [{input: input, use_count: use_count}, {input: input, use_count: use_count}, ...] This would mean a change to the history storage format. It'd be backward compatible, though, since we're only adding things and older clients would just silently ignore it. That said, they'd might replace the record with one that doesn't have the information, so upping the storage format for history would be the safest route. The timing seems good in light of bug 603489. We would also need to add support for this to the async Places APIs we're speccing out.

We've lived without this for a long time, I don't think it's imperative for Fx4. Wanted for sure.

As a anecdotal data point, I set up Firefox on my new laptop using only Sync... While it feels ~80% the same as my old Firefox, this seems to be the one major thing that keeps it from feeling the same.

I'm not sure this has to be or would best be implemented as a separate Sync engine. Much like frecency, input history is closely tied to history.

(In reply to comment #6) > I'm not sure this has to be or would best be implemented as a separate Sync > engine. Much like frecency, input history is closely tied to history. That's why it's "sync-engine-addition" rather than "new-sync-engine" :)

I have a couple of questions: I use the location bar dropdown (by clicking the arrow at the end) as the startpoint for most of my browsing. When I set up a new profile somewhere and Sync it, this menu is very different and doesn't contain the sites I'm used to until it has been trained. Will this bug fix that? The other question is how will different profiles merge this data with each other? How do you combine the adaptive behaviour of one profile with another? Thanks.

> I use the location bar dropdown (by clicking the arrow at the end) as the > startpoint for most of my browsing. When I set up a new profile somewhere and > Sync it, this menu is very different and doesn't contain the sites I'm used to > until it has been trained. Will this bug fix that? If sites are actually missing from your bookmarks or history (i.e., you can't find them at all with the awesome bar) then no. If they're simply not in the usual order, then yes. > The other question is how will different profiles merge this data with each > other? How do you combine the adaptive behaviour of one profile with another? Figuring that out is the first part of this bug! It's not even obvious to me that syncing this data cross-device is the correct default.

(In reply to comment #9) > > I use the location bar dropdown (by clicking the arrow at the end) as the > > startpoint for most of my browsing. When I set up a new profile somewhere and > > Sync it, this menu is very different and doesn't contain the sites I'm used to > > until it has been trained. Will this bug fix that? > > If sites are actually missing from your bookmarks or history (i.e., you can't > find them at all with the awesome bar) then no. > > If they're simply not in the usual order, then yes. I was referring to what appears when you open a new tab and click the dropdown arrow at the end of the location bar (without typing anything). For me, it's a list of 12 sites. I've been using this as a replacement for the bookmarks toolbar in that it covers the sites I visit most, and so with just 2 clicks I can get to where I want (e-mail, Facebook, news etc.) In a new profile which has Sync set up, I get 12 sites, but they're not usually the same ones and so it don't serve the purpose that I use it for. After a bit of training, I can get it to be the same, or almost the same, as my original profile. My question was whether this bug would cause that dropdown list of sites to be the same across Sync-ed profiles. For me, it would be good if it did!

(In reply to comment #10) > My question was whether this bug would cause that dropdown list of sites to be > the same across Sync-ed profiles. For me, it would be good if it did! Yes, those are computed based on frecency (which we sync) and inputhistory (which is this bug). Syncing both should cause the observed behavior that you desire.