Consider a user with Sync configured to sync tabs and history. A "remote tab" for such users is almost guaranteed to have 2 redundant entries - the (synced) visit and the remote tab entry, and these 2 redundant entries are often separated by irrelevant entries. Further, the "visit" entry is likely to be near the top of the list, but doesn't indicate it is a "remote" visit, making it difficult for the user to see that is the entry they are looking for. I think we can improve this by merging the 2 entries, especially now that we have the newly designed wide URLBar. For example, earlier today I followed a link from Twitter on my laptop. The page title is "The Voyeur's Motel". I wanted to find this remote tab, so typed "Voy" into the URLBar. The end result is as attached: * The top-entry is the remote visit to this URL - but there's no indication this is actually the remote tab (I've never visited that URL on the device the screen-shot was taken on) * The next entry is the t.co redirection to the article in question (IMO this should not be shown at all - I'm guessing that's bug 737836?) * The next 3 entries are URLs that happen to have "voy" in the URL (but not the title). I suspect if more URLs matched this pattern we would have removed the remote tab entry completely! * Finally I have the "remote tab" - which is an exact duplicate of the first URL (but it has the correct favicon, so we have that going for us, which is nice :) I propose that we change how that first entry is rendered to reflect that this is a visit *and* it is opened on the remote device (eg, by putting the device name(s) before the URL). I believe this would make it clearer that it is the page I'm looking for. This might also go some way towards mitigating bug 1261220 - the fact that the remote visit is redundant just makes it more likely the "remote tab" entry will be pushed off the list completely, thereby giving zero indication to the user that the tab is open remotely. What do you think?

CC Drew as he is doing some urlbar work and may have thoughts here...

Sounds good to me. From an implementation perspective it shouldn't be too hard to do.

Bug 1433938 should have fixed this.