Add metrics for setting document.domain.

Add metrics for setting document.domain.

We should probably have a UseCounter to see what usage looks
like for this feature.

BUG=none

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=192274

[davidben, 2015-03-18 01:06:41]

davidben@chromium.org changed reviewers:
+ nasko@chromium.org

[nasko, 2015-03-18 16:33:52]

nasko@chromium.org changed reviewers:
+ creis@chromium.org, dcheng@chromium.org

[nasko, 2015-03-18 16:33:52]

Adding Charlie, as he might be interested and dcheng@, as I'm no owner in this
area.

[dcheng, 2015-03-18 16:40:14]

Several questions:

1) What is the motivation? Are we thinking about removing this?

2) Would it be better to use MeasureAs=Foo in the idl like
https://codereview.chromium.org/1007683002?

3) Is there a Chrome-side CL? It looks like
https://code.google.com/p/chromium/codesearch#chromium/src/tools/metrics/hist...
is out-of-date?

[Charlie Reis, 2015-03-18 16:49:55]

Thanks Nasko.  David, ping me if you get data from this-- I'd be very interested
to know how often it's modified!

[davidben, 2015-03-18 17:21:55]

On 2015/03/18 16:40:14, dcheng wrote:
> Several questions:
> 
> 1) What is the motivation? Are we thinking about removing this?

Mostly just wondering what the numbers are. It's why Site Isolation has to be
Site (eTLD+1) Isolation rather than Origin Isolation, so I think it's worth
having a handle on its use. And, yeah, if it turns out to be used infrequently,
I would love to remove it.

If you're not familiar, setting document.domain *changes* your effective script
origin from (scheme, host, port) to (scheme, WHAT-YOU-SET, magic-value). It
means that which documents can mutually script each other can change
dynamically, which is crazy. It also means that our process isolation must
assume any two documents that could *possibly* become scriptable-same-origin
will and put them in the same process.

(Of course, I don't actually work on Site Isolation and I assume you folks might
want to use eTLD+1 for resource usage reasons anyway. But it'd be nice for it to
be just for resource usage reasons.)

> 2) Would it be better to use MeasureAs=Foo in the idl like
> https://codereview.chromium.org/1007683002

That would measure gets as well as sets. Gets are pretty tame. It's the sets
that are scary.

> 3) Is there a Chrome-side CL? It looks like
>
https://code.google.com/p/chromium/codesearch#chromium/src/tools/metrics/hist...
> is out-of-date?

Yeah, it seems to get out-of-date a lot with the repository split. Once this
lands, there's a script to sync up histograms.xml. I was planning on running it
and uploading a CL right afterwards.

[dcheng, 2015-03-20 00:54:49]

On 2015/03/18 at 17:21:55, davidben wrote:
> On 2015/03/18 16:40:14, dcheng wrote:
> > Several questions:
> > 
> > 1) What is the motivation? Are we thinking about removing this?
> 
> Mostly just wondering what the numbers are. It's why Site Isolation has to be
Site (eTLD+1) Isolation rather than Origin Isolation, so I think it's worth
having a handle on its use. And, yeah, if it turns out to be used infrequently,
I would love to remove it.
> 
> If you're not familiar, setting document.domain *changes* your effective
script origin from (scheme, host, port) to (scheme, WHAT-YOU-SET, magic-value).
It means that which documents can mutually script each other can change
dynamically, which is crazy. It also means that our process isolation must
assume any two documents that could *possibly* become scriptable-same-origin
will and put them in the same process.
> 
> (Of course, I don't actually work on Site Isolation and I assume you folks
might want to use eTLD+1 for resource usage reasons anyway. But it'd be nice for
it to be just for resource usage reasons.)
> 
> > 2) Would it be better to use MeasureAs=Foo in the idl like
> > https://codereview.chromium.org/1007683002
> 
> That would measure gets as well as sets. Gets are pretty tame. It's the sets
that are scary.
> 
> > 3) Is there a Chrome-side CL? It looks like
> >
https://code.google.com/p/chromium/codesearch#chromium/src/tools/metrics/hist...
> > is out-of-date?
> 
> Yeah, it seems to get out-of-date a lot with the repository split. Once this
lands, there's a script to sync up histograms.xml. I was planning on running it
and uploading a CL right afterwards.

lgtm

[davidben, 2015-03-20 00:55:54]

The CQ bit was checked by davidben@chromium.org

[commit-bot: I haz the power, 2015-03-20 00:56:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1017903003/20001

[commit-bot: I haz the power, 2015-03-20 00:59:23]

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

[commit-bot: I haz the power, 2015-03-20 00:59:25]

Try jobs failed on following builders:
  mac_blink_compile_dbg on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/mac_blink_compile_dbg/bu...)
  mac_blink_rel on tryserver.blink (JOB_FAILED,
http://build.chromium.org/p/tryserver.blink/builders/mac_blink_rel/builds/48326)

[davidben, 2015-03-20 17:32:49]

The CQ bit was checked by davidben@chromium.org

[davidben, 2015-03-20 17:32:50]

The patchset sent to the CQ was uploaded after l-g-t-m from dcheng@chromium.org
Link to the patchset: https://codereview.chromium.org/1017903003/#ps60001
(title: "actually rebase")

[commit-bot: I haz the power, 2015-03-20 17:33:37]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1017903003/60001

[commit-bot: I haz the power, 2015-03-20 19:04:27]

Committed patchset #4 (id:60001) as
https://src.chromium.org/viewvc/blink?view=rev&revision=192274