Add a field trial for the HTML preload scanner.

Add a field trial for the HTML preload scanner.

This is the field trial side of
https://codereview.chromium.org/1196193005/

R=japhet@chromium.org,bmcquade@chromium.org, rdsmith@chromium.org
BUG=None

Committed: https://crrev.com/a3c8aa067d8c1482a39cfdbe78106de21abe31b0
Cr-Commit-Position: refs/heads/master@{#335855}

[gavinp, 2015-06-22 19:49:38]

bmccquade: PTAL.

japhet: FYI.

[gavinp, 2015-06-22 21:11:16]

gavinp@chromium.org changed reviewers:
+ bmcquade@chromium.org
- bmccquade@chromium.org

[gavinp, 2015-06-22 21:12:08]

Fixed the spelling of bmcquade@chromium.org, whoops!

[gavinp, 2015-06-22 21:12:16]

bmcquade: PTAL.

[gavinp, 2015-06-22 21:12:46]

See https://codereview.chromium.org/1196193005/ for a blink change that uses
this setting. There's at present no about:flags handling.

[Bryan McQuade, 2015-06-23 13:42:15]

On 2015/06/22 21:12:46, gavinp wrote:
> See https://codereview.chromium.org/1196193005/ for a blink change that uses
> this setting. There's at present no about:flags handling.

lgtm (pending lgtm on the blink-side change)

[gavinp, 2015-06-23 15:38:12]

The CQ bit was checked by gavinp@chromium.org

[commit-bot: I haz the power, 2015-06-23 15:39:36]

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

[commit-bot: I haz the power, 2015-06-23 15:39:39]

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

[commit-bot: I haz the power, 2015-06-23 15:39:39]

No L-G-T-M from a valid reviewer yet. Only full committers are accepted.
Even if an L-G-T-M may have been provided, it was from a non-committer,
_not_ a full super star committer.
See http://www.chromium.org/getting-involved/become-a-committer
Note that this has nothing to do with OWNERS files.

[gavinp, 2015-06-23 15:56:59]

gavinp@chromium.org changed reviewers:
+ rdsmith@chromium.org

[gavinp, 2015-06-23 15:56:59]

+rdsmith


rdsmith: PTAL

[Randy Smith (Not in Mondays), 2015-06-23 16:24:45]

Sorry, you may have picked the wrong reviewer, just because I'm not willing to
stamp without understanding what's going on, and I really don't understand
what's going on yet.  Hopefully it won't take too long to bring me up to speed.

Questions:
* What are the parameters used for the HtmlPreloadScanning field trial?  Where
are they documented in the source?  (I presume in blink.)  
* The reason for the above question: Given that
MaybeAppendBlinkSettingsSwitchForFieldTrial smashes all the params for all the
different field trials into a single mass before passing them to blink through
the command line, are the parameter names I requested above unique enough (sic)
between field trials to likely avoid future conflicts?
* Could you describe the mechanism used to turn Source/core/frame/Settings.in
into initialization of CachedDocumentParameters::doHtmlPreloadScanning?

Thanks much in advance ...

[gavinp, 2015-06-23 17:21:25]

On 2015/06/23 16:24:45, rdsmith wrote:
> Sorry, you may have picked the wrong reviewer, just because I'm not willing to
> stamp without understanding what's going on, and I really don't understand
> what's going on yet.  Hopefully it won't take too long to bring me up to
speed.
> 
> Questions:
> * What are the parameters used for the HtmlPreloadScanning field trial?  Where
> are they documented in the source?  (I presume in blink.)  

They are not documented in the source. The field trials themselves will add
finch parameters, which will end up concatenated with the "blink-settings"
command line flag.

> * The reason for the above question: Given that
> MaybeAppendBlinkSettingsSwitchForFieldTrial smashes all the params for all the
> different field trials into a single mass before passing them to blink through
> the command line, are the parameter names I requested above unique enough
(sic)
> between field trials to likely avoid future conflicts?

The names themselves are guaranteed unique, because there are specified in
Settings.in in blink, which guards itself against duplicates by virtue of
generating C++ code to create the settings object.

> * Could you describe the mechanism used to turn Source/core/frame/Settings.in
> into initialization of CachedDocumentParameters::doHtmlPreloadScanning?

As part of the blink build, Settings.in generates the Settings object, which
sits on the Document. So in the initializer of CachedDocumentParameters, the
call to:

  document->settings()->doHtmlPreloadScanning()

is going directly in to that.

As well, the settings object parses the "blink-settings" command line flag,
which gets pushed to blink via "ApplyBlinkSettings" in the unnamed namespace in
render_view_impl.cc

> 
> Thanks much in advance ...

[Randy Smith (Not in Mondays), 2015-06-23 20:49:31]

I'm not completely happy with the idiom--I'd rather seem a bit more
documentation *somewhere* along the chain for allowed values of params for each
trial--but that's not the fault of this CL.  LGTM.

[Bryan McQuade, 2015-06-23 23:39:05]

On 2015/06/23 20:49:31, rdsmith wrote:
> I'm not completely happy with the idiom--I'd rather seem a bit more
> documentation *somewhere* along the chain for allowed values of params for
each
> trial--but that's not the fault of this CL.  LGTM.

For better or worse, the parameter parsing logic is autogenerated from
Settings.in
(https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...).
The autogenerated code that parses these params can be seen here:
https://code.google.com/p/chromium/codesearch#chromium/src/out/Debug/gen/blin...

[gavinp, 2015-06-24 00:22:55]

The CQ bit was checked by gavinp@chromium.org

[commit-bot: I haz the power, 2015-06-24 00:23:37]

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

[Randy Smith (Not in Mondays), 2015-06-24 00:39:30]

On 2015/06/23 23:39:05, Bryan McQuade wrote:
> On 2015/06/23 20:49:31, rdsmith wrote:
> > I'm not completely happy with the idiom--I'd rather seem a bit more
> > documentation *somewhere* along the chain for allowed values of params for
> each
> > trial--but that's not the fault of this CL.  LGTM.
> 
> For better or worse, the parameter parsing logic is autogenerated from
> Settings.in
>
(https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...).
> The autogenerated code that parses these params can be seen here:
>
https://code.google.com/p/chromium/codesearch#chromium/src/out/Debug/gen/blin...

Yeah, I wasn't willing to stamp until I looked at that code.  It's not the
autogeneration I object to, it's the lack of documentation (auto- or manually
generated)  in the chromium or blink source to guide people in what they put in
the finch trial controls.  Which could be added if it was the coder culture to
do so.  But I have the impression that blink culture is less in favor of
in-comment documentation than chromium culture.

[commit-bot: I haz the power, 2015-06-24 02:04:20]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-06-24 02:05:21]

Patchset 1 (id:??) landed as
https://crrev.com/a3c8aa067d8c1482a39cfdbe78106de21abe31b0
Cr-Commit-Position: refs/heads/master@{#335855}