New issue
Advanced search Search tips

Issue 759803 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocked on:
issue 728727



Sign in to add a comment

History page may re-query for deduped items

Project Member Reported by s...@chromium.org, Aug 28 2017

Issue description

Right now the history page (on all platforms) sets a QueryOptions::DuplicateHandling policy to filter out results for the same URL.

The problem, is that we also set QueryOptions::max_count, and make multiple requests by using QueryOptions::end_time to page through history.

However, when a duplicate is removed, this history result's timestamp is discarded. When we go to make the next request, we set end_time to the smallest timestamp that we received. If the smallest timestmaps that were encountered were deduped, we then re-fetch then on the next request, and we don't dedupe these results correctly.

It would be more correct if QueryResults contained, in a separate field, the smallest time that was encountered, even if it was removed by deduplication. This would be incrementally more correct than the current behavior.

An alternative would be to not use any History DB deduplication, and do it all in the BrowsingHistoryService, but this may be significantly less performant.

Note that we still don't 100% remove deduplication problems, as separate requests are not checking against eachothers' results.
 
Components: Privacy
Might this cause problem for timed clear browsing data?

Comment 2 by s...@chromium.org, Sep 28 2017

If by "timed clear browsing data", you mean chrome://settings/clearBrowserData, then no. That is going to take a time range back to the history thread, and delete everything inside that range. There's no deduplication based on URL involved, so nothing is ever missed.

If by "timed clear browsing data", you mean going to chrome://history and deleting everything that's visually in a certain time range, then no - except on iOS when searching for a query string (at least as of writing). And that's because when we issue deletions to the local history db, we construct a day long time range around the actual visit time, which is the same range that we were deduping (except on iOS searching for text where the dedupe range is bigger), so we don't actually miss anything.
Labels: Hotlist-Privacy
Status: Available (was: Untriaged)

Sign in to add a comment