DRTs should not share the IndexedDB directory path.
Created attachment 313902 [details] Patch
Comment on attachment 313902 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=313902&action=review > Source/WebKit/win/ChangeLog:8 > + DRTs should not share the IndexedDB directory path, as this can cause flakiness. This change is not specific to DRT, is it?
After this change, will apps using indexeddb be able to find their files that are already stored on people's disks?
(In reply to Alex Christensen from comment #3) > After this change, will apps using indexeddb be able to find their files > that are already stored on people's disks? That's a good point. If the app has set the 'WebDatabaseDirectory' preference, the indexeddb files will then have a new location with this patch. Otherwise, the files will be located at the same place. Thanks for reviewing!
(In reply to Alex Christensen from comment #2) > Comment on attachment 313902 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=313902&action=review > > > Source/WebKit/win/ChangeLog:8 > > + DRTs should not share the IndexedDB directory path, as this can cause flakiness. > > This change is not specific to DRT, is it? That's correct.
Comment on attachment 313902 [details] Patch I think this should be fixed by having DRT set the IndexedDB directory. If there is not a way to do so, we should make a way and use the default directory if it isn't set to avoid breaking existing apps by having them not find existing files after updating WebKit.
(In reply to Alex Christensen from comment #6) > Comment on attachment 313902 [details] > Patch > > I think this should be fixed by having DRT set the IndexedDB directory. If > there is not a way to do so, we should make a way and use the default > directory if it isn't set to avoid breaking existing apps by having them not > find existing files after updating WebKit. Sounds good, Alex, I think I will create a new preference for the IndexedDB directory. Sorry for the long response time!
Seems to be AppleWin port related, I think we can mark this as 'RESOLVED CONFIGURATION CHANGED'.