On launch this was one of our banner features in Chrome -- full text search over your browsing history. I wrote some of the code. I believe we (Google's Chrome team) implemented (and contributed back) SQLite's full text search support exactly to make this feature.
I don't know why it was removed (after my time) but I do know it had a lot of problems.
1) Most users were unaware of the feature, and it's hard to find a way for them to discover it.
2) The index costs a lot of disk space, which makes #1 worse. There's a whole bunch of tradeoffs around how much storage to use vs how much history to keep. Pages that self-reload can cause the index to bloat endlessly (a real bug we had).
3) Having an index of pages locally is not sufficient to make a useful search engine. There's a lot of ranking involved in making google search good. Similarly we tried to show "snippets" of page text that showed why we showed the results we did and that itself requires a lot of effort to be useful.
#2 and #3 are just bugs that can be fixed with more effort, but it's hard to motivate that effort in the presence of #1.
(FWIW, the sibling comment about how it was removed to favor google.com searches isn't plausible to me, that's not how the Chrome team works.)
I'd be happy if it did it just for bookmarked pages. I have often wanted that in bookmark search and it could be incorporated directly into the bookmark searchbar.
Me too! In fact, when I think about it, bookmarks are such a nebulous thing. It's like I want them to do two diametrically opposed jobs.
On the one hand, when I have a bookmark for a site like HN, I want it to give me a quick way to get to the front page and see the latest posts so I can read and discuss them. In this case, the bookmark is serving like a pointer to an address whose contents are subject to change.
On the other hand, I bookmark pages with specific information I want to keep so I can refer back to it later. This is where bookmarks often fail me. Websites are transient by nature and bookmarks are extremely vulnerable to link rot. What I think I'd really want is a bookmark that saves an archive of the page so that I'll always have access to the information in its original form, even if the page changes or the site goes down. In this case, the bookmark is functioning more like a constant than a variable.
I'm aware that browsers such as Safari have the ability to save a page as a web archive file which includes all the data needed to render the page in its original form. The problem is that this feature completely punts on the issue of managing a set of these web archives, delegating that task to the Finder. I want a UI that is more integrated into the browser. If I bookmark a site it should save and manage the archive automatically. Full text search on all my bookmark archived pages should be built into the address bar. Perhaps in order to avoid the conflict between the two uses of bookmarks described above there could be a difference between favourites and bookmarks.
I don't know, does anyone else have any thoughts about this stuff?
We built Memex for that combination of use cases in mind.
So right now you can already full-text search your bookmarks, and filter by time, domain and tags. Already on the mid-term roadmap we plan to enable full-html/text snapshots of visited pages, both locally and on-demand. For the latter we are potentially working with the Internet Archive.
Agree with #3, I built a similar tool with Rails/Elastic search/React couple of years back. It never returned the most relevant results on top. Realized Elastic search can only do that if I could add back-links for ranking and for adding back-links (I could be wrong) I would have to crawl the entire internet.
I don't know why it was removed (after my time) but I do know it had a lot of problems.
1) Most users were unaware of the feature, and it's hard to find a way for them to discover it.
2) The index costs a lot of disk space, which makes #1 worse. There's a whole bunch of tradeoffs around how much storage to use vs how much history to keep. Pages that self-reload can cause the index to bloat endlessly (a real bug we had).
3) Having an index of pages locally is not sufficient to make a useful search engine. There's a lot of ranking involved in making google search good. Similarly we tried to show "snippets" of page text that showed why we showed the results we did and that itself requires a lot of effort to be useful.
#2 and #3 are just bugs that can be fixed with more effort, but it's hard to motivate that effort in the presence of #1.
(FWIW, the sibling comment about how it was removed to favor google.com searches isn't plausible to me, that's not how the Chrome team works.)