Tracking bug for cases where Clear Recent History and the Forget button underperform, i.e. leave data behind that shouldn't be left behind. Theoretically this can be split into three categories: 1. site-specific data with or without timestamp left behind when clearing "everything" (no time range) 2. site-specific data with timestamp left behind when clearing a time range covering that timestamp 3. site-specific data without timestamp left behind when clearing a time range covering the time when that data was added, meaning that we're not leaking that the user definitely visited the site at that time, but we're still leaking that the user visited the site at all, which likely goes against the user's intent especially when the site was never visited before the selected time range This bug explicitly does not track cases where data clearing is overzealous (e.g. bug 771630).

I prioritized the bugs currently tracked with the priority field. As a rule of thumb, I prioritized data persisted by web sites (e.g. indexedDB) higher than manually stored data that web sites can't directly access (e.g. cookie exceptions), and the lowest priority went to more obscure transient data and caches that go away automatically after some certain time or after a restart.

I believe the most concise and intuitive GUI for maintaining persistent user data is to enhance the Privacy settings section by creating a new item for each kind of persistence mechanism, resembling the Cookies privacy settings (see my attachments for visualization).

Version (a) adds a new paragraph to the Privacy settings section for LocalStorage and a new paragraph for IndexedDB. Version (b) adds a tab strip - providing a tab for Cookies, LocalStorage, and IndexedDB. All sharing the same set of input elements within their tabs, respectively.