When clicking on a bookmark result we want to measure time in seconds since creation, seconds since the last visit and the total number of visits.

This sounds this would be implemented using 3 separate exponential histograms.

API-wise, we don't have such information off-hand. More specifically: - bookmark creation time can be gathered through the bookmarks API - last visit can be gathered through the history result API, but it's expensive. - we do not have an API to get number of visits to an url. Mostly because we never needed it for common UI operations. History.jsm::fetch, once implemented, may cover the history needs here. This is still 2 fetches and 2 roundtrips to the disk, but considered it only happens on confirmation it may be acceptable. We could also consider doing this when we fetch results and pass the info to the UI, but it may require to make every single result a moz-action result to be able to attach info to it. Finally, we could consider a custom query, even if off-hand I'd not be thrilled about that.

Let's talk about these, if they're hard or expensive, we should cut them for v1 (and perhaps cut them entirely). Marco, do you think the other aspects are reasonable, such as query length, time in milliseconds, result position, input mechanism, etc. Those are very compelling if we can do them, and interesting to compare across many result types (search, history, bookmarks)

(In reply to Javaun Moradi [:javaun] from comment #3) > Marco, do you think the other aspects are reasonable, such as query length, > time in milliseconds, result position, input mechanism, etc. Those are very > compelling if we can do them, and interesting to compare across many result > types (search, history, bookmarks) Yes, that kind of information can be gathered synchronously in the UI code, I'm mostly worried about information that lies on disk, and thus requires us to I/O roundtrip to collect it.