expose frecency as a sort order for place queries. something along the lines nsINavHistoryQueryOptions.SORT_BY_FRECENCY_DESCENDING / ASCENDING. this could be useful for extension authors or for people wanting to do interesting things with place: queries. note: in our search term builder (at some point) we want to have ui for all (or most) of our query options, but having "Frecency" in the UI is going to be tough to localize. spun off from bug #411293

some bad software call it "relevance", IIRC.

We'll need this if we want a smartbookmark type thing that shows the top 10 most frecent pages. The query would be something like.. SELECT url, title FROM moz_places ORDER BY frecency DESC LIMIT 10 But I see some existing super-optimized stuff for nsNavHistory::ConstructQueryString And we would either need to return another column for frecency or just keep it internal and sort on it for the general non-optimized/frecency ASC query... ?

(In reply to comment #2) > SELECT url, title FROM moz_places ORDER BY frecency DESC LIMIT 10 if you come to see those into the Library probably you will need more then those 2 columns. an optimized query should limit before selecting, nothing fancy here

So do something like.. SELECT <desired columns> FROM moz_places WHERE id IN ( SELECT id FROM moz_places ... LIMIT 10)

yes, similar to the actual most visited query or history menu query <desired columns> should be the same as other queries (based on index definition in the file)

Ondrej: Would you be able to add a new sort order for frecency seeing that you're familiar with the results code from working on bug 385245? Sorting would just use the frecency column in moz_places. Potentially we might want a "super-optimized" version as well.

This should be the same case as visit_count, so very easy to implement. No super-optimized version is needed.

(In reply to comment #7) > No super-optimized version is needed. it depends if we need to join with moz_historyvisits, in that case we should always limit in the inner select, this depends where we want to expose this frecency, if we create a smart frecency bookmark and the user will open that into the library we will need also history columns

Any news here? It would be great to have it fixed for Firefox 3.1.

We probably don't want to actually call this "frecency" if we add the collumn, given that it will be hard to localize things that aren't actually words. Perhaps popularity?

what about "relevance" as Mano suggested in comment #1

yeah, relevance sounds ok

Approving blocking+ for the 3.1 release. This has been requested by extension authors, sync implementors, and will be needed internally for other 3.1 features.

Bug 455651 was cut from 3.1, so this doesn't need to block the release.

would be great for extension developers and sync services, marking wanted+ and keeping on 3.1 radar.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv

was implemented in bug 630225.