'Clear Recent History' with 'Cache' or 'Offline Website Data' doesn't clear QuotaManager storage (indexedDB, asm.js cache)

REOPENED
Unassigned

Status

()

Core
DOM
P1
normal
REOPENED
3 years ago
3 months ago

People

(Reporter: luke, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
Points:
---
Bug Flags:
firefox-backlog +

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
One might expect 'Clear Recent History' (with 'Cache' checked) to clear asm.js cache entries and (with 'Offline Website Data' checked) to clear IDB storage, but neither do.  Currently, the only way to clear this is buried deep down in Page Info -> Permissions -> Maintain Offline Storage.

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 527667

Updated

3 years ago
Blocks: 1102808
Status: RESOLVED → REOPENED
Flags: firefox-backlog+
Resolution: DUPLICATE → ---
Summary: 'Clear Recent History' with 'Cache' or 'Offline Website Data' doesn't clear QuotaManager storage → 'Clear Recent History' with 'Cache' or 'Offline Website Data' doesn't clear QuotaManager storage (indexedDB, asm.js cache)

Updated

3 years ago
Duplicate of this bug: 602743

Comment 3

3 years ago
How would this work with time ranges for these stores?  For example, only deleting the last hour of IDB changes for an origin seems hard unless we are going to snapshot the quota dir on every change.

Updated

3 years ago
Priority: -- → P1
(Reporter)

Comment 4

3 years ago
The QuotaManager maintains the last access time (which is access, not creation); perhaps it could also maintain creation time?  Alternatively, we might be able to use the creation time (returned by PR_GetFileInfo) of the associated storage dir, although perhaps this would be fooled by file movements (version upgrades, etc)?

Comment 5

3 years ago
Whats the desired behavior here?  Consider for the moment:

1) IDB database is created 1 month ago.
2) User accumulates data in IDB over the course of the month.
3) Current browsing session modifies the IDB database 1 minute ago.
4) User clicks "forget last 5 minutes".

What should happen?

1) Delete the entire IDB database?
2) Backout the edits from the last 5 minutes only?

I think (1) would be surprising and (2) might be hard to implement in an efficient way.

Note, I'm interested in this because I'm building a new QuotaManager storage engine for the ServiceWorker Cache.

Comment 6

3 years ago
(In reply to Ben Kelly [:bkelly] from comment #5)
> Whats the desired behavior here?  Consider for the moment:
> 
> 1) IDB database is created 1 month ago.
> 2) User accumulates data in IDB over the course of the month.
> 3) Current browsing session modifies the IDB database 1 minute ago.
> 4) User clicks "forget last 5 minutes".
> 
> What should happen?
> 
> 1) Delete the entire IDB database?
> 2) Backout the edits from the last 5 minutes only?
> 
> I think (1) would be surprising and (2) might be hard to implement in an
> efficient way.
> 
> Note, I'm interested in this because I'm building a new QuotaManager storage
> engine for the ServiceWorker Cache.

I don't think doing (2) is a good idea, regardless of implementation problems and performance.
QuotaManager doesn't have knowledge of data stored in IDB, so deleting all edits done in last 5 minutes can mess up the database. Even if we reverted whole transactions (some operations can consist of multiple transactions).

So, one option is to just support the "Everything" time range for now.

Comment 7

3 years ago
Right, I meant QM would have to call back to the IDB client with a "Forget(timerange)" and then IDB would have to do extra work to implement it.  Sounds like a ton of effort.

Updated

2 years ago
Duplicate of this bug: 1135370

Updated

2 years ago
Duplicate of this bug: 1146522

Updated

2 years ago
Duplicate of this bug: 986616

Updated

2 years ago
Duplicate of this bug: 1206515
See Also: → bug 781984
Duplicate of this bug: 1214445
See Also: → bug 1108265

Comment 13

2 years ago
IDB should be part of "Offline Web Content and User Data". If you clear that, it should clear the IndexedDB too.

Updated

2 years ago
Flags: needinfo?(luke)

Comment 14

2 years ago
Bug 1047098,602743,506692,357704,536544,600367
Flags: needinfo?(luke)

Updated

2 years ago
Duplicate of this bug: 1231559

Comment 16

2 years ago
(In reply to Ben Kelly [:bkelly] from comment #5)
> Whats the desired behavior here?  Consider for the moment:
> 
> 1) IDB database is created 1 month ago.
> 2) User accumulates data in IDB over the course of the month.
> 3) Current browsing session modifies the IDB database 1 minute ago.
> 4) User clicks "forget last 5 minutes".
> 
> What should happen?
> 
> 1) Delete the entire IDB database?
> 2) Backout the edits from the last 5 minutes only?
> 
> I think (1) would be surprising and (2) might be hard to implement in an
> efficient way.
> 
> Note, I'm interested in this because I'm building a new QuotaManager storage
> engine for the ServiceWorker Cache.

I think the solution is this:

1. Show a check box for clearing Offline Storage (including IDB)
2. If user chooses to remove all, then it delets that too
3. If use selects a time-limited option (e.g. last month), then FF does the following:
    a. If an IDB was created within that time, it's deleted
    b. If any IDB is older (not nec. the data in it though) than the timeframe, then an alert is popped up warning the user that one or more IDB's are older, shows them a list with checkboxes next to each and asks them to select the ones they want to delete

Comment 17

2 years ago
That sounds good to me.

Comment 18

2 years ago
Is there a special reason to provide the ability to select a timed range for deleting the cache? I wonder how often this is used and if it is effectively really useful for these people. Is there any telemetry data available for this?

Comment 19

2 years ago
(In reply to sworddragon2 from comment #18)
> Is there a special reason to provide the ability to select a timed range for
> deleting the cache? I wonder how often this is used and if it is effectively
> really useful for these people. Is there any telemetry data available for
> this?

It's very important and should be added to the Android version.

Remember it's not just deleting the cache, but offline data (cookies, site settings, etc can be in this)

Comment 20

2 years ago
I've stumbled over this issue too, after I noticed directories named after websites I had visited long ago in <profile>/storage/{default,temporary}, even though my preferences include a Clear All History at exit with everything selected.

This was certainly disconcerting, and difficult to research.

I'm not against local storage, but it feels like when one requests a total wipe out, they kinda expect a total wipe out.

A remark about donrhummy's solution in comment 16: if step 3 is difficult and takes time to implement (it looks like it needs a lot of coding), how about only supporting timerange=Everything for now, as suggested by previous posters? Perhaps with something like:

3. If user selects a time-limited option (e.g. last month), gray out the box for IndexedDB data and don't delete any
Duplicate of this bug: 1201842

Comment 22

2 years ago
(In reply to sworddragon2 from comment #18)
> Is there a special reason to provide the ability to select a timed range for
> deleting the cache? I wonder how often this is used and if it is effectively
> really useful for these people. Is there any telemetry data available for
> this?

Deleting a timed range of the cache has never actually worked, see bug 646975. It's always completely cleared.

IndexedDB should certainly not be treated that way! I think it would be reasonable to delete any databases created within the specified time, and just not touch any older than that.

Otherwise, a UI like in comment 16, but 3.b. should only present a list of older databases that have actually been modified within the specified time range. An in-between method could be to simply show an alert that the following older databases have been modified within the time range, but won't be deleted, which is likely what the user wants.

Comment 23

a year ago
What the user likely wants when clearing all data is this:

>it feels like when one requests a total wipe out, they kinda expect a total wipe out.

which isn't happening as we speak.

If I choose to delete all data (especially *local storage*) with time range *everything* , I don't want to see anything left there, not just read an alert that something has been modified -unless I misunderstood your comment above, in which case I apologize.

Comment 24

a year ago
(In reply to msth67 from comment #23)
> What the user likely wants when clearing all data is this:
> 
> >it feels like when one requests a total wipe out, they kinda expect a total wipe out.
> 
> which isn't happening as we speak.
> 
> If I choose to delete all data (especially *local storage*) with time range
> *everything* , I don't want to see anything left there, not just read an
> alert that something has been modified -unless I misunderstood your comment
> above, in which case I apologize.

The issue with the timerange is that IDB does not keep track of exactly what data has been added/edited/deleted during time frames. And even if it did, how would you undo the changes? It would need to keep full copies of all data and their past changes just like a source control system. That's not possible and would take too much space on the drive. So the databases can only be relied on to give creation time, and nothing more.

Comment 25

a year ago
(In reply to msth67 from comment #23)
> If I choose to delete all data (especially *local storage*) with time range
> *everything* , I don't want to see anything left there, not just read an
> alert that something has been modified -unless I misunderstood your comment
> above, in which case I apologize.

If the user chooses to clear "Everything", all databases should simply be erased immediately, no question. My comment above was about when a time range like "Last Hour" is chosen, and there's a database that has six months worth of data in it, which has been modified in the last hour. Since it's not practical to delete the last hour's worth of transactions, what should be done?

(In reply to donrhummy from comment #24)
> So the databases can only be relied on to give creation time,
> and nothing more.

According to comment 4, there's not even a reliable method to get the creation time.

At this point, the suggestion in comment 6 to at least support the "Everything" option for now, seems like a good idea. The security/privacy risk of sites using IndexedDB for "supercookies" etc., is mitigated by the fact that the user has to authorize the creation of any persistent databases via an alert. Still, there should be a UI to delete them if desired.

Comment 26

3 months ago
(In reply to Elhem Enohpi from comment #25)
> The security/privacy
> risk of sites using IndexedDB for "supercookies" etc., is mitigated by the
> fact that the user has to authorize the creation of any persistent databases
> via an alert. Still, there should be a UI to delete them if desired.

Except that doesn't work as users expect either… (bug 959985)
You need to log in before you can comment on or make changes to this bug.