Clearing passwords clears HTTP authentication credentials, too, so we need to close all sockets, as they may in fact have been created using those credentials.

So this is behaving as expected.  We could consider just flushing the socket pools, so existing connections would go away on complete, but not sure how reliable that is (I'm not sure Authenticated HTTP2 proxy sessions with live requests, for example, would go away on complete), nor if keeping live authenticated sockets is really something we should be doing in this case.  So I think this is probably WontFix, but CCing relevant folks, in case they disagree.


Relevant code:

https://cs.chromium.org/chromium/src/chrome/browser/browsing_data/chrome_browsing_data_remover_delegate.cc?l=839
https://cs.chromium.org/chromium/src/chrome/browser/browsing_data/chrome_browsing_data_remover_delegate.cc?l=261

Hmm, with hosted apps data it's probably an actual bug. Hosted apps data means "site data for hosted apps", i.e. local storage et al. for websites which have an associated hosted app in chrome://apps, but not cookies. Cookies are always only deleted with "cookies and site data".

You can see in browsing_data_remover_impl.cc that DATA_TYPE_COOKIE is usually accompanied by ORIGIN_TYPE_UNPROTECTED_WEB (the latter means NOT hosted apps). However, the HTTP auth credentials deletion does not check the latter.

This is a one line fix, but in the longer term, we should probably just make sure that deleting "Hosted apps data" requests a deletion for DATA_TYPE_SITE_DATA & ~DATA_TYPE_COOKIES so that we don't have to check ORIGIN_TYPE.

For passwords, however, I agree that this is working as intended.

Shouldn't we be deleting data from that particularly hosted app's cookie store, and auth cache?

For passwords, even if disrupting active network traffic is intended, wouldn't that warrant a small note or warning upon checking "Passwords" that all network traffic will be disrupted (or only if there is an active upload or download)?