So, Chrome has a pretty neat New Tab page where it shows recently closed tabs and windows (click image below to enlarge it). But guess what happens when you click the “View Full History” link? It doesn’t show you what you’d expect―the full list of closed tabs and windows. Instead, it shows you your standard history of pages.
![]()
One of the rules of good interface design should be store as much user data as possible. User input is sacred. Infinite undo history is good. All data matters. There’s no reason to throw anything away. Saving the full history of tabs doesn’t cost anything but it creates a lot of value. So, do it.
December 26th, 2009
by Peter Kasting
Actually, storing the state of the tabs costs quite a bit. Remember, you’re not just storing a URL; you’re storing the complete state of the tab so you can restore it as the user left it. This adds up fast. We keep more than you see on the new tab page–the last 10 close actions–but beyond that, diminishing returns kicks in.
I’d love to see us store, say, the last 100 closed items, but the cost is prohibitive.
December 26th, 2009
by Abi Raja
The Author
If I’m not wrong, Chrome already stores the full text of each page (I know this because when I search in the location bar or on the history page, it shows me results with the keyword in the content of the page; tangent: if I recall correctly, page titles are for some reason not weighted higher than in-page matches) so I’m not sure how storing the complete state of the tab could be higher than that (I mean, the state of a tab is simply the tab opener/parent tab + a list of history items, isn’t it?).
But I did confound two different things in the post – saving user data and the fact that the label on the Recently Closed section is still wrong. The latter is definitely something you should fix.
December 27th, 2009
by Colby Russell
So, Firefox has a pretty neat bookmarks organizer where it shows bookmarks sortable by various criteria. But guess what happens when you click the “All Bookmarks” item? It doesn’t show what you’d expect―the full list of your filed, unfiled, tagged, and untagged bookmarks. Instead, it shows the bookmarks toolbar, the menubar, and “unsorted bookmarks” items.
December 27th, 2009
by Colby Russell
PS: That’s bug 528304.
December 29th, 2009
by Peter Kasting
“if I recall correctly, page titles are for some reason not weighted higher than in-page matches”
You do not recall correctly. (I wrote this code, so I’m certain.)
Neither is weighted as highly as a URL prefix match, though.
“the state of a tab is simply the tab opener/parent tab + a list of history items, isn’t it?”
No, the state of a tab involves the serialized DOM, JS virtual machine state, etc. Right now we don’t remember everything because for things like GMail that could mean hundreds of megabytes of data, but we still remember a lot.
“the label on the Recently Closed section is still wrong”
While I take your meaning, it’s not so obviously wrong, with an obviously better alternative, as you might think. Your history of visited pages is the same as your history of closed pages (modulo anything currently open), but sorted in a different order. Once you’ve gone past a dozen or so closed pages, listing things in visit order rather than close order is probably more intuitive. So I think what we’re doing is actually OK.
I think it might be slightly better to add a divider between the last closed item and the history link, or give it a different background color, or make it a button.
FWIW, your post is the first complaint I’ve ever heard about it :)
January 12th, 2010
by Abi Raja
The Author
Colby, thanks for the note. Did not realize that.
Peter, I think I wrote the wrong observation. What I observed was that non-prefix URL matches are for some reason not ranked higher then in-page matches. Is that true? For example, I often search for “reader” to find “http://google.com/reader” but that doesn’t work well on Chrome but it does in Firefox. I think non-prefix URL matches are pretty important.
Well, just storing the history of each tab (with opener) would be useful in this case and that alone shouldn’t take up too much space.
“…listing things in visit order rather than close order is probably more intuitive.” I highly doubt this although a hybrid might be the best we can achieve here. Right now, there’s no information at all about tabs in history. I do agree that this isn’t a major issue (that’s what I’ve been saying all along! It isn’t major but I was still worth noting the mistake).
January 12th, 2010
by Peter Kasting
Let me see if I am correctly understanding your question. You are asking if it is true that, for the input “foo”, and two identically-visited URLs, where one matches in the URL (”http://sample.com/foo/…”) and the other matches in the page body text, Chrome will give them equal weighting in the address bar drop down?
If so, then yes, that is currently true. Both the URL and the fulltext are fed to the fulltext repository, which is the source of the matches in these cases.
It would be possible to rewrite this to weight URL matches more highly. In general non-prefix URL matching is not a case we have focused much on, partly because much of the design of the omnibox backend happened before the existence of the “Awesomebar” and its popularization of this style of matching, and partly because it’s a bit tricky to do this well and still preserve the sorts of invariants around synchronous results that we need to have for inline autocomplete to work. As a result, addressing this is nebulous and shuffled far behind other, pressing issues on my plate. Patches welcome :)
January 12th, 2010
by Abi Raja
The Author
Yep, that was my question. And my point is that assigning equal weighting to both is a bad idea. Clearly, “reader” in a subsection of a page doesn’t mean anything to the user’s memory compared with “reader” in the URL. Although I don’t think the only reason such matching is useful is because people are habituated to the Awesomebar, I can understand why it might be difficult to do this well. Thanks!
January 13th, 2010
by Peter Kasting
It’s not really “clear” that the page content is less memorable than the URL. If I read a story on the New York Times, it’s likely that I never even paid attention to the URL, whereas the page content is much more memorable.
Part of the reason (though not all) for the omnibox design is that the majority of users neither understand nor care about URLs. They don’t distinguish them from searches, they don’t do a lot of typing them in; they visit their sports or news or whatever sites and click links, they open emails sent by their friends, they search and then click search result links. Instead of elevating the ranking of URL matches, it would be better to elevate the ranking of “important” pages. Frequency and recency can both be signals of page importance, but there are dozens of others, such as time spent on page, the quantity of unique content, and the relevance of the search term to the page (either through dumb arithmetic like “how many times does this appear” or sophisticated content analysis done by server-side algorithms).
January 30th, 2010
by Abi Raja
The Author
I think you need some way to figure out the importance of words within a page then. I experimented with using Open Calais[1] once to try to figure out what the most important words on a page were and the results weren’t too bad. So, that could be one approach.
[1] http://abcdefu.wordpress.com/2009/01/26/heres-to-the-lazy-ones-lazybar/