Introduce DATA_TYPE_DOM_STORAGE for DOM-Accessible storage

Introduce DATA_TYPE_DOM_STORAGE for DOM-Accessible storage

Clear-Site-Data specifies a "storage" datatype, representing DOM-accessible
storage. This corresponds to the 7 storage datatypes in BrowsingDataRemover,
and possibly others defined in the embedder.

We define the DATA_TYPE_EMBEDDER_DOM_STORAGE pseudo-datatype that serves as
a signal for the embedder delegate to delete its DOM-accessible storage.
Then, we define DATA_TYPE_DOM_STORAGE as a group datatype (bitmask) of the
abovementioned 7 storage datatypes and DATA_TYPE_EMBEDDER_STORAGE.

See the design doc for the rationale for this approach.
https://docs.google.com/document/d/1I6m4QwbTNhG6wdtazamhTnArJN-UMUGqpvwH6InBEaM/edit#heading=h.q2f5zo9hgn7o

Currently, the only datatype in Chrome that is related to DOM storage is
DURABLE_PERMISSION (considering that PLUGIN_DATA is currently deleted
by Clear-Site-Data as part of "cookies"). The other datatypes, such as
WEB_APP_DATA and SITE_USAGE_DATA are only metadata that Chrome keeps.
Therefore, replacing DATA_TYPE_SITE_DATA with DATA_TYPE_DOM_STORAGE in
ChromeContentBrowserClient::ClearSiteData() is also a functional change
to Clear-Site-Data, weakening it to only delete DOM-accessible storage.

BUG=668114
Review-Url: https://codereview.chromium.org/2745323004
Cr-Commit-Position: refs/heads/master@{#457046}
Committed: https://chromium.googlesource.com/chromium/src/+/f4ab8376fc0e86d3a8e6516256711c9da85002c3

[msramek, 2017-03-14 16:02:06]

The CQ bit was checked by msramek@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-14 16:03:06]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-14 17:08:51]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 17:08:52]

Dry run: This issue passed the CQ dry run.

[msramek, 2017-03-14 21:44:56]

Description was changed from

==========
Introduce DATA_TYPE_DOM_STORAGE for DOM-Accessible storage

Clear-Site-Data specifies a "storage" datatype, representing DOM-accessible
storage. This corresponds to the 7 storage datatypes in BrowsingDataRemover,
and possibly others defined in the embedder.

We define the DATA_TYPE_EMBEDDER_DOM_STORAGE pseudo-datatype that serves as
a signal for the embedder delegate to delete its DOM-accessible storage.
Then, we define DATA_TYPE_DOM_STORAGE as a group datatype (bitmask) of the
abovementioned 7 storage datatypes and DATA_TYPE_EMBEDDER_STORAGE.

See the design doc for the rationale for this approach.
https://docs.google.com/document/d/1I6m4QwbTNhG6wdtazamhTnArJN-UMUGqpvwH6InBE...

BUG=668114
==========

to

==========
Introduce DATA_TYPE_DOM_STORAGE for DOM-Accessible storage

Clear-Site-Data specifies a "storage" datatype, representing DOM-accessible
storage. This corresponds to the 7 storage datatypes in BrowsingDataRemover,
and possibly others defined in the embedder.

We define the DATA_TYPE_EMBEDDER_DOM_STORAGE pseudo-datatype that serves as
a signal for the embedder delegate to delete its DOM-accessible storage.
Then, we define DATA_TYPE_DOM_STORAGE as a group datatype (bitmask) of the
abovementioned 7 storage datatypes and DATA_TYPE_EMBEDDER_STORAGE.

See the design doc for the rationale for this approach.
https://docs.google.com/document/d/1I6m4QwbTNhG6wdtazamhTnArJN-UMUGqpvwH6InBE...

Currently, the only datatype in Chrome that is related to DOM storage is
DURABLE_PERMISSION (considering that PLUGIN_DATA is currently deleted
by Clear-Site-Data as part of "cookies"). The other datatypes, such as
WEB_APP_DATA and SITE_USAGE_DATA are only metadata that Chrome keeps.

BUG=668114
==========

[msramek, 2017-03-14 22:01:03]

Description was changed from

==========
Introduce DATA_TYPE_DOM_STORAGE for DOM-Accessible storage

Clear-Site-Data specifies a "storage" datatype, representing DOM-accessible
storage. This corresponds to the 7 storage datatypes in BrowsingDataRemover,
and possibly others defined in the embedder.

We define the DATA_TYPE_EMBEDDER_DOM_STORAGE pseudo-datatype that serves as
a signal for the embedder delegate to delete its DOM-accessible storage.
Then, we define DATA_TYPE_DOM_STORAGE as a group datatype (bitmask) of the
abovementioned 7 storage datatypes and DATA_TYPE_EMBEDDER_STORAGE.

See the design doc for the rationale for this approach.
https://docs.google.com/document/d/1I6m4QwbTNhG6wdtazamhTnArJN-UMUGqpvwH6InBE...

Currently, the only datatype in Chrome that is related to DOM storage is
DURABLE_PERMISSION (considering that PLUGIN_DATA is currently deleted
by Clear-Site-Data as part of "cookies"). The other datatypes, such as
WEB_APP_DATA and SITE_USAGE_DATA are only metadata that Chrome keeps.

BUG=668114
==========

to

==========
Introduce DATA_TYPE_DOM_STORAGE for DOM-Accessible storage

Clear-Site-Data specifies a "storage" datatype, representing DOM-accessible
storage. This corresponds to the 7 storage datatypes in BrowsingDataRemover,
and possibly others defined in the embedder.

We define the DATA_TYPE_EMBEDDER_DOM_STORAGE pseudo-datatype that serves as
a signal for the embedder delegate to delete its DOM-accessible storage.
Then, we define DATA_TYPE_DOM_STORAGE as a group datatype (bitmask) of the
abovementioned 7 storage datatypes and DATA_TYPE_EMBEDDER_STORAGE.

See the design doc for the rationale for this approach.
https://docs.google.com/document/d/1I6m4QwbTNhG6wdtazamhTnArJN-UMUGqpvwH6InBE...

Currently, the only datatype in Chrome that is related to DOM storage is
DURABLE_PERMISSION (considering that PLUGIN_DATA is currently deleted
by Clear-Site-Data as part of "cookies"). The other datatypes, such as
WEB_APP_DATA and SITE_USAGE_DATA are only metadata that Chrome keeps.
Therefore, replacing DATA_TYPE_SITE_DATA with DATA_TYPE_DOM_STORAGE in
ChromeContentBrowserClient::ClearSiteData() is also a functional change
to Clear-Site-Data, weakening it to only delete DOM-accessible storage.

BUG=668114
==========

[msramek, 2017-03-14 22:07:11]

Patchset #1 (id:1) has been deleted

[msramek, 2017-03-14 22:07:17]

The CQ bit was checked by msramek@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-03-14 22:08:01]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[msramek, 2017-03-14 22:09:45]

msramek@chromium.org changed reviewers:
+ mkwst@chromium.org

[msramek, 2017-03-14 22:09:45]

Hi Mike,

Please have a look! The solution is slightly different than we talked about
today, in fact, it's sort of a middle point between the two options. I
elaborated on my choice in the design doc.

Thanks,
Martin

[commit-bot: I haz the power, 2017-03-14 22:18:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-14 22:18:19]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[msramek, 2017-03-14 22:29:49]

The CQ bit was checked by msramek@chromium.org to run a CQ dry run

[msramek, 2017-03-14 22:30:00]

Patchset #1 (id:20001) has been deleted

[commit-bot: I haz the power, 2017-03-14 22:30:45]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-15 00:12:30]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-03-15 00:12:31]

Dry run: This issue passed the CQ dry run.

[Mike West, 2017-03-15 08:09:47]

I like this approach, thanks for the explanation in the design doc. LGTM.

I think it would be helpful to move some of that explanation into a `.md` file
in the `browsing_data` directory. That, of course, doesn't need to happen in
this patch, but it would be good to get some documentation going in the
repository.

[msramek, 2017-03-15 10:05:17]

Thanks, Mike!

Regarding the documentation, I have it on my radar! My plan is to basically
condense the design doc into README.md when the refactoring is finished (which
is, I think, 1 CL away :) ).

[msramek, 2017-03-15 10:05:23]

The CQ bit was checked by msramek@chromium.org

[commit-bot: I haz the power, 2017-03-15 10:05:34]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-03-15 10:10:44]

CQ is committing da patch.

Bot data: {"patchset_id": 40001, "attempt_start_ts": 1489572323164000,
"parent_rev": "79d9faff8de3edc85007f4923f8da415f5bd917c", "commit_rev":
"f4ab8376fc0e86d3a8e6516256711c9da85002c3"}

[commit-bot: I haz the power, 2017-03-15 10:11:23]

Description was changed from

==========
Introduce DATA_TYPE_DOM_STORAGE for DOM-Accessible storage

Clear-Site-Data specifies a "storage" datatype, representing DOM-accessible
storage. This corresponds to the 7 storage datatypes in BrowsingDataRemover,
and possibly others defined in the embedder.

We define the DATA_TYPE_EMBEDDER_DOM_STORAGE pseudo-datatype that serves as
a signal for the embedder delegate to delete its DOM-accessible storage.
Then, we define DATA_TYPE_DOM_STORAGE as a group datatype (bitmask) of the
abovementioned 7 storage datatypes and DATA_TYPE_EMBEDDER_STORAGE.

See the design doc for the rationale for this approach.
https://docs.google.com/document/d/1I6m4QwbTNhG6wdtazamhTnArJN-UMUGqpvwH6InBE...

Currently, the only datatype in Chrome that is related to DOM storage is
DURABLE_PERMISSION (considering that PLUGIN_DATA is currently deleted
by Clear-Site-Data as part of "cookies"). The other datatypes, such as
WEB_APP_DATA and SITE_USAGE_DATA are only metadata that Chrome keeps.
Therefore, replacing DATA_TYPE_SITE_DATA with DATA_TYPE_DOM_STORAGE in
ChromeContentBrowserClient::ClearSiteData() is also a functional change
to Clear-Site-Data, weakening it to only delete DOM-accessible storage.

BUG=668114
==========

to

==========
Introduce DATA_TYPE_DOM_STORAGE for DOM-Accessible storage

Clear-Site-Data specifies a "storage" datatype, representing DOM-accessible
storage. This corresponds to the 7 storage datatypes in BrowsingDataRemover,
and possibly others defined in the embedder.

We define the DATA_TYPE_EMBEDDER_DOM_STORAGE pseudo-datatype that serves as
a signal for the embedder delegate to delete its DOM-accessible storage.
Then, we define DATA_TYPE_DOM_STORAGE as a group datatype (bitmask) of the
abovementioned 7 storage datatypes and DATA_TYPE_EMBEDDER_STORAGE.

See the design doc for the rationale for this approach.
https://docs.google.com/document/d/1I6m4QwbTNhG6wdtazamhTnArJN-UMUGqpvwH6InBE...

Currently, the only datatype in Chrome that is related to DOM storage is
DURABLE_PERMISSION (considering that PLUGIN_DATA is currently deleted
by Clear-Site-Data as part of "cookies"). The other datatypes, such as
WEB_APP_DATA and SITE_USAGE_DATA are only metadata that Chrome keeps.
Therefore, replacing DATA_TYPE_SITE_DATA with DATA_TYPE_DOM_STORAGE in
ChromeContentBrowserClient::ClearSiteData() is also a functional change
to Clear-Site-Data, weakening it to only delete DOM-accessible storage.

BUG=668114

Review-Url: https://codereview.chromium.org/2745323004
Cr-Commit-Position: refs/heads/master@{#457046}
Committed:
https://chromium.googlesource.com/chromium/src/+/f4ab8376fc0e86d3a8e651625671...
==========

[commit-bot: I haz the power, 2017-03-15 10:11:24]

Committed patchset #1 (id:40001) as
https://chromium.googlesource.com/chromium/src/+/f4ab8376fc0e86d3a8e651625671...