Bug 187564 – IndexedDB: database file of subframe cannot be removed

• Component: WebKit API
• Status: RESOLVED FIXED

[Sihui Liu]

Steps to reproduce:
1. Visit a website(e.g. google.com) with subframe that loads content from another domain(e.g. ads.com) and uses IndexedDB.
2. Call removeDataOfTypes function to remove IndexedDB.
IndexedDB files at PathToIndexedDB/https_google.com_0/https_ads.com_0/DBName/ are not deleted; files at PathToIndexedDB/https_google.com_0/DBName/ are deleted.

[Sihui Liu]

<rdar://problem/41649536>

[Sihui Liu]

Created attachment 344784 [details]
Patch

[Ryosuke Niwa]

Comment on attachment 344784 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=344784&action=review

> Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:1018
> +				935786CD20F6A2910000CDFC /* IndexedDB.sqlite3 in Copy Resources */,
> +				935786CE20F6A2A10000CDFC /* IndexedDB.sqlite3-shm in Copy Resources */,
> +				935786CC20F6A2700000CDFC /* IndexedDB.sqlite3-wal in Copy Resources */,

Looks like your patch is missing these files.

[Sihui Liu]

Created attachment 344819 [details]
Patch

[Sihui Liu]

(In reply to Ryosuke Niwa from comment #3)
> Comment on attachment 344784 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=344784&action=review
> 
> > Tools/TestWebKitAPI/TestWebKitAPI.xcodeproj/project.pbxproj:1018
> > +				935786CD20F6A2910000CDFC /* IndexedDB.sqlite3 in Copy Resources */,
> > +				935786CE20F6A2A10000CDFC /* IndexedDB.sqlite3-shm in Copy Resources */,
> > +				935786CC20F6A2700000CDFC /* IndexedDB.sqlite3-wal in Copy Resources */,
> 
> Looks like your patch is missing these files.

Wops! Fixed.

[youenn fablet]

Comment on attachment 344819 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=344819&action=review

> Source/WebCore/ChangeLog:10
> +        IDBServer should delete database files recursively to make sure all files are removed.

LGTM.

Let's say that we have the following IDB databases:
IDB1: top level frame origin A with subframe origin A
IDB2: top level frame origin A with subframe origin B
IDB3: top level frame origin B with subframe origin A.
IDB4: top level frame origin B with subframe origin C.

When user asks to delete all databases from origin A, we should probably delete IDB1, IDB2 and IDB3.

Before the patch, it seems we were deleting IDB1.
After the patch, we are also deleting IDB2.
Is that right? What about IDB3?

[Sihui Liu]

(In reply to youenn fablet from comment #6)
> Comment on attachment 344819 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=344819&action=review
> 
> > Source/WebCore/ChangeLog:10
> > +        IDBServer should delete database files recursively to make sure all files are removed.
> 
> LGTM.
> 
> Let's say that we have the following IDB databases:
> IDB1: top level frame origin A with subframe origin A
> IDB2: top level frame origin A with subframe origin B
> IDB3: top level frame origin B with subframe origin A.
> IDB4: top level frame origin B with subframe origin C.
> 
> When user asks to delete all databases from origin A, we should probably
> delete IDB1, IDB2 and IDB3.
> 
> Before the patch, it seems we were deleting IDB1.
> After the patch, we are also deleting IDB2.
> Is that right? What about IDB3?

Correct!

IDB3 won't get deleted. We classify the IndexedDB data record by their top level domain.

[WebKit Commit Bot]

Comment on attachment 344819 [details]
Patch

Clearing flags on attachment: 344819

Committed r233777: <https://trac.webkit.org/changeset/233777>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[youenn fablet]

> > Let's say that we have the following IDB databases:
> > IDB1: top level frame origin A with subframe origin A
> > IDB2: top level frame origin A with subframe origin B
> > IDB3: top level frame origin B with subframe origin A.
> > IDB4: top level frame origin B with subframe origin C.
> > 
> > When user asks to delete all databases from origin A, we should probably
> > delete IDB1, IDB2 and IDB3.
> > 
> > Before the patch, it seems we were deleting IDB1.
> > After the patch, we are also deleting IDB2.
> > Is that right? What about IDB3?
> 
> Correct!
> 
> IDB3 won't get deleted. We classify the IndexedDB data record by their top
> level domain.

We should probably file a bug and find a fix to delete IDB3 as well.
I believe we are already doing this clean-up for Cache API and Service Worker registrations.

[Sihui Liu]

(In reply to youenn fablet from comment #10)
> > > Let's say that we have the following IDB databases:
> > > IDB1: top level frame origin A with subframe origin A
> > > IDB2: top level frame origin A with subframe origin B
> > > IDB3: top level frame origin B with subframe origin A.
> > > IDB4: top level frame origin B with subframe origin C.
> > > 
> > > When user asks to delete all databases from origin A, we should probably
> > > delete IDB1, IDB2 and IDB3.
> > > 
> > > Before the patch, it seems we were deleting IDB1.
> > > After the patch, we are also deleting IDB2.
> > > Is that right? What about IDB3?
> > 
> > Correct!
> > 
> > IDB3 won't get deleted. We classify the IndexedDB data record by their top
> > level domain.
> 
> We should probably file a bug and find a fix to delete IDB3 as well.
> I believe we are already doing this clean-up for Cache API and Service
> Worker registrations.

Sure. Created a new bug for tracking: https://bugs.webkit.org/show_bug.cgi?id=187631.

[Brent Fulgham]

*** Bug 188164 has been marked as a duplicate of this bug. ***