So far as I can tell, databases-incognito is for the actual databases (opened with DELETE_ON_CLOSE, see issue 345720) whereas the OpenInMemory() is only for the TrackerDatabase itself (i.e. the database-of-databases)

Hi,

I cannot reproduce this. Is it fixed?

Still reproduces for me using 66.0.3359.117 (Official Build) (64-bit) on Windows 10 64-bit.

1. Open an incognito tab and load http://html5test.com/.
2. While the tab is open navigate to the Profile Path directory listed in chrome://version/ (e.g. C:\Users\[User]\AppData\Local\Google\Chrome\User Data\Default)
3. Notice a databases-incognito directory with today's timestamp.
4. Close the incognito tab and the databases-incognito directory is removed.

Thank you, reproduced.

Comment #3 says it's created for the databases that maybe created later. Do you suggest that it would be just delayed to when it's required?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bb833a07a0e8d1ca8222c697d55867ca301eb2a6

commit bb833a07a0e8d1ca8222c697d55867ca301eb2a6
Author: Joshua Bell <jsbell@chromium.org>
Date: Wed Oct 17 22:11:27 2018

WebSQL: Support deletion backing stores in Incognito mode.

Chrome's WebSQL implementation handles incognito mode by creating
delete-on-exit directories (see crbug.com/779689). When an particular
origin is getting deleted (e.g. via devtools) an origin-specific
directory needs to get deleted. The logic to compute the directory
path differs for incognito and non-incognito sessions, and there was a
logic mismatch between the creation and deletion code.

Additionally, the actual database files are marked "delete on close"
and this necessitated holding onto file handles for the lifetime
of the tracker to handle open/close/re-open. But when the origin is
deleted, these handles need to be dropped.

Refactor so a single method is used to compute the directory path in
all cases, and drop handles when the origin is deleted.

Bug: 779689,  876659 
Change-Id: Idaf53ff407246c4dc3f66cdd84d2d4075b969d8e
Reviewed-on: https://chromium-review.googlesource.com/c/1277698
Reviewed-by: Victor Costan <pwnall@chromium.org>
Reviewed-by: Christian Dullweber <dullweber@chromium.org>
Reviewed-by: Ramin Halavati <rhalavati@chromium.org>
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#600574}
[modify] https://crrev.com/bb833a07a0e8d1ca8222c697d55867ca301eb2a6/chrome/browser/browsing_data/browsing_data_remover_browsertest.cc
[modify] https://crrev.com/bb833a07a0e8d1ca8222c697d55867ca301eb2a6/storage/browser/database/database_tracker.cc
[modify] https://crrev.com/bb833a07a0e8d1ca8222c697d55867ca301eb2a6/storage/browser/database/database_tracker.h
[modify] https://crrev.com/bb833a07a0e8d1ca8222c697d55867ca301eb2a6/storage/browser/database/database_tracker_unittest.cc

jsbell@,

What do you thing about #10? Can we delay creating the folder to when we need to create a database?

Looks like this would require refactoring everything using DatabaseTracker::LazyInit - seems plausible, though. 

Thank you.

I will snooze it till the end of Q1,2019, and will assign priority to it base on our general decision on WebSQL.