Thanks for the report.

I would say that the general requirement is that chrome://settings/clearBrowserData is able to clear (almost) everything persistently stored in the regular profile. Data stored temporarily in memory by incognito can be, after all, cleared by closing the incognito session. I also understand the fact that chrome://settings/clearBrowserData always opens in the regular mode, even if navigated to from incognito, as a hint that the incognito mode actually *doesn't* have this dialog, so it shouldn't be that surprising that deletions only pertain to the regular mode.

It's possible that there are various inconsistencies when are things cleared only from the regular mode and when also from incognito, caused by the fact that some data types have separate storages for incognito, some data types don't, and some inherit data from the regular mode and can build atop of them in incognito. However, incognito cookies are also not deleted by the Clear Browsing Data dialog. I think that not clearing the session storage is consistent with that, and I would not consider a) a bug.

Regarding b) is it ever possible in the regular mode that the session storage would contain data that are not immediately flushed to disk? If yes, and after clearing "Cookies and site data" these data would remain accessible to websites, and possibly even *later* flushed to the disk, then I agree that's worth fixing.

Thanks for you analysis.

About your remark on b) it confirms that this is just how chromium browser is supported to work. By curiosity I compared with Firefox and it behaves differently than chromium browser (and chrome). Indeed for Firefox, even if the incognito mode actually *doesn't* have the "clearBrowserData" dialog too then the data stored temporarily in memory are still deleted.
This is this Firefox's behavior that we want in our embedded case. But since it is browser dependent I understand that it could be different in chromium.

About your question on b) I have not encountered this case but I do not think this could happen. Even if it is asynchronous between browser process (disk+cache) and renderer process (cache), both side can notify the other on any update. But in any case what you mentioned should be a c) unless I misunderstood :)

About b) I was more referring to the case where session storage is not persistent on disk in normal browsing mode. (so if a custom browser does not call GetDOMStorageContext()->SetSaveSessionStorageOnDisk()).
Then chrome://settings/clearBrowserData *doesn't* clear the temp memory for session storage.
Is it like a), i.e. just how chromium browser is supposed to work ? Thx.

Thanks for the explanation. My stance here would be:


1. For incognito, I prefer to leave the behavior consistent with cookies, i.e. don't delete anything.

As a side note, perhaps we eventually *should* allow deletions for incognito mode together with the regular mode, or allow the clear browsing data dialog to be opened in incognito. But as long as we don't do that, we should keep the behavior consistent among different data types.


2. For the regular mode, it depends. I would argue that if a custom chromium-based browser stores things differently, it is their responsibility to also delete them differently. No need to land the change upstream.

However, if it is possible that Chromium itself stores the data in memory in regular mode (i.e. with some configuration of build flags), or if it simply doesn't require much code to put in such a safeguard just-in-case, then I'm OK with fixing this. It still shouldn't affect incognito though.

I will leave it to the code owners to make that call.

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

commit 8d07be600b13008d0fcbb1608eef835eadd171a0
Author: j.isorce <j.isorce@samsung.com>
Date: Thu May 05 20:06:35 2016

Allow to clear session and local storage when not backed on disk

This patch allow GetLocalStorageUsage and GetSessionStorageUsage
to return non empty UsageInfo so that one can call DeleteLocalStorage
and DeleteSessionStorage.

Which both internally call DOMStorageContextImpl::NotifyAreaCleared to
send DOMStorageMsg_Event IPC from browser process to renderer process.
On receiver side DomStorageDispatcher calls
blink::WebStorageEventDispatcher::dispatch to clear the cache from the
LocalFrame.

BUG= 604745 

R=michaeln@chromium.org, msramek@chromium.org

Review-Url: https://codereview.chromium.org/1900793003
Cr-Commit-Position: refs/heads/master@{#391886}

[modify] https://crrev.com/8d07be600b13008d0fcbb1608eef835eadd171a0/content/browser/dom_storage/dom_storage_context_impl.cc
[modify] https://crrev.com/8d07be600b13008d0fcbb1608eef835eadd171a0/content/browser/dom_storage/dom_storage_namespace.cc
[modify] https://crrev.com/8d07be600b13008d0fcbb1608eef835eadd171a0/content/browser/dom_storage/dom_storage_namespace.h