Add ExecuteJavaScriptForTest and make all tests use it

Add ExecuteJavaScriptForTest and make all tests use it

Additionally, restrict the URLs that ExecuteJavaScript can be invoked on
to chrome-controlled URLs.

R=jam@chromium.org
BUG=507809
Committed: https://crrev.com/904f14ebdc3bdb8e893df0a3211d09de42d5619c
Cr-Commit-Position: refs/heads/master@{#340231}

[mdjones, 2015-05-06 21:01:25]

mdjones@chromium.org changed reviewers:
+ mdjones@chromium.org

[mdjones, 2015-05-06 21:01:26]

jochen@ The reader mode pages are closely controlled by us similar to how the
internal/UI pages are, would it be possible to white-list the "chrome-distiller"
scheme as well? Any javascript we run on the source page will still be run in an
isolated world but we would like to be able to execute javascript directly on
our pages.

[jochen (gone - plz use gerrit), 2015-05-07 05:07:16]

On 2015/05/06 at 21:01:26, mdjones wrote:
> jochen@ The reader mode pages are closely controlled by us similar to how the
internal/UI pages are, would it be possible to white-list the "chrome-distiller"
scheme as well? Any javascript we run on the source page will still be run in an
isolated world but we would like to be able to execute javascript directly on
our pages.

Do chrome-distiller:// pages include javascript from the original page?

[mdjones, 2015-05-07 15:44:12]

On 2015/05/07 05:07:16, jochen wrote:
> On 2015/05/06 at 21:01:26, mdjones wrote:
> > jochen@ The reader mode pages are closely controlled by us similar to how
the
> internal/UI pages are, would it be possible to white-list the
"chrome-distiller"
> scheme as well? Any javascript we run on the source page will still be run in
an
> isolated world but we would like to be able to execute javascript directly on
> our pages.
> 
> Do chrome-distiller:// pages include javascript from the original page?

No, any javascript being run is coming from us. Our CSP also denies external and
in-line scripts.

[jam, 2015-05-07 17:00:41]

lgtm

[jochen (gone - plz use gerrit), 2015-07-16 04:53:16]

jochen@chromium.org changed reviewers:
+ torne@chromium.org

[jochen (gone - plz use gerrit), 2015-07-16 04:53:17]

ptal

we're down to DOM distiller now.

Matthew tells me that they run the distiller on its own url scheme (instead of
e.g. chrome://distiller/) because it can't guarantee to not also include script
from the webpage. This makes me worry whether allowing script injection is the
right way forward here. In any case, we'd need an content API that allows for
whitelisting schemes (which might get abused in the future).

Alternatives would be to run the distiller script in an isolated world, or move
the distiller to chrome://distiller/ (which would still give it a distinct
security origin anyways with "distiller" as the host0

https://codereview.chromium.org/1123783002/diff/250001/content/public/browser...
File content/public/browser/render_frame_host.h (right):

https://codereview.chromium.org/1123783002/diff/250001/content/public/browser...
content/public/browser/render_frame_host.h:41: static void
AllowInjectingJavaScriptForAndroidWebView();
Richard & John, ptal esp. at this method

There is no compile-time way to differentiate between Android WebView and
regular Android builds, however, the webview exposes an evaluateJavascript API
to embedders, so we can't restrict the call.

[Torne, 2015-07-16 12:41:57]

android_webview LGTM

https://codereview.chromium.org/1123783002/diff/250001/content/public/browser...
File content/public/browser/render_frame_host.h (right):

https://codereview.chromium.org/1123783002/diff/250001/content/public/browser...
content/public/browser/render_frame_host.h:41: static void
AllowInjectingJavaScriptForAndroidWebView();
On 2015/07/16 04:53:17, jochen wrote:
> Richard & John, ptal esp. at this method
> 
> There is no compile-time way to differentiate between Android WebView and
> regular Android builds, however, the webview exposes an evaluateJavascript API
> to embedders, so we can't restrict the call.

This seems reasonable to me.

[jochen (gone - plz use gerrit), 2015-07-23 22:01:18]

The CQ bit was checked by jochen@chromium.org

[jochen (gone - plz use gerrit), 2015-07-23 22:01:18]

The patchset sent to the CQ was uploaded after l-g-t-m from jam@chromium.org,
torne@chromium.org
Link to the patchset: https://codereview.chromium.org/1123783002/#ps270001
(title: "rebase")

[commit-bot: I haz the power, 2015-07-23 22:02:40]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1123783002/270001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1123783002/270001

[commit-bot: I haz the power, 2015-07-23 23:50:47]

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

[commit-bot: I haz the power, 2015-07-23 23:50:48]

Try jobs failed on following builders:
  linux_android_rel_ng on tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_android_r...)

[jochen (gone - plz use gerrit), 2015-07-24 04:03:58]

The CQ bit was checked by jochen@chromium.org

[commit-bot: I haz the power, 2015-07-24 04:04:56]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1123783002/270001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1123783002/270001

[commit-bot: I haz the power, 2015-07-24 06:41:05]

Committed patchset #15 (id:270001)

[commit-bot: I haz the power, 2015-07-24 06:41:36]

Patchset 15 (id:??) landed as
https://crrev.com/904f14ebdc3bdb8e893df0a3211d09de42d5619c
Cr-Commit-Position: refs/heads/master@{#340231}

[sof, 2015-07-24 08:16:58]

sigbjornf@opera.com changed reviewers:
+ sigbjornf@opera.com

[sof, 2015-07-24 08:16:58]

Causing meltdown on most bots?


http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux/builds/51422

http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20Leak/bu...

[sof, 2015-07-24 08:40:16]

A revert of this CL (patchset #15 id:270001) has been created in
https://codereview.chromium.org/1257603003/ by sigbjornf@opera.com.

The reason for reverting is: Speculatively reverting to address failures,


http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux/builds/51422.