Avoid leaking favicons when page URL contains fragments (aka refs)
When updating icon->page URL mappings, the code has historically associated icons to both the original page URL as well as the fragment-stripped page URL (for page URLs that contain a fragment/ref). This can cause "orphan" entries in the favicon database, i.e. mappings that don't have a corresponding history entry (because the page URL without a fragment was never actually visited). This means the history expirer will never take care of cleaning them up, leaking until the user clears all history. The original logic was introduced to fix crbug.com/498618 which is no longer reproducible even after this patch. With recent improvements in client-side redirect handling (e.g. https://chromium-review.googlesource.com/569760 or https://chromium-review.googlesource.com/595977), it is conceivable that these historical heuristics are no longer needed. Since this is hard to prove, we put the new behavior behind a feature than can be experimented via Chrome variations. Bug: 746268 Change-Id: Ieefb0fdb175d8858f1055af2dcc54df2e6f00a9a Reviewed-on: https://chromium-review.googlesource.com/649691 Commit-Queue: Mikel Astiz <mastiz@chromium.org> Reviewed-by:Brett Wilson <brettw@chromium.org> Cr-Commit-Position: refs/heads/master@{#506510}
Showing
Please register or sign in to comment