Blank UI for web component tests.

Blank UI for web component tests.

This UI will let us test a variety of Polymer elements by navigating
to this UI in a browser test, then including the files to test. Many
of the files we want to test include chrome:// URLs, which is why this
WebUI is useful to have.

This is the first of 3 CLs to enable support for testing web
components in Chrome. chrome://web-component-test/ will be augmented
to work with Mocha and provide a simple framework for async Polymer
tests.

BUG=482770

[michaelpg, 2015-05-05 12:11:25]

michaelpg@chromium.org changed reviewers:
+ jhawkins@chromium.org

[michaelpg, 2015-05-05 12:12:46]

Part One.

[stevenjb, 2015-05-05 22:24:59]

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

[stevenjb, 2015-05-05 22:25:00]

lgtm with comment

https://codereview.chromium.org/1128543002/diff/40001/chrome/browser/ui/webui...
File chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc (right):

https://codereview.chromium.org/1128543002/diff/40001/chrome/browser/ui/webui...
chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc:306: return
&NewWebUI<WebComponentTestUI>;
Either alphabetize this or put a comment above this with why it is listed first
(and space the comment from lines 303-304).

[michaelpg, 2015-05-08 16:57:39]

https://codereview.chromium.org/1128543002/diff/40001/chrome/browser/ui/webui...
File chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc (right):

https://codereview.chromium.org/1128543002/diff/40001/chrome/browser/ui/webui...
chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc:306: return
&NewWebUI<WebComponentTestUI>;
On 2015/05/05 22:25:00, stevenjb wrote:
> Either alphabetize this or put a comment above this with why it is listed
first
> (and space the comment from lines 303-304).

Done. (No reason for it to be first, I just forgot to re-sort after changing the
name.)

[michaelpg, 2015-05-14 02:54:26]

Patchset #5 (id:80001) has been deleted

[michaelpg, 2015-05-14 03:05:58]

@jhawkins: ping

[James Hawkins, 2015-05-14 15:16:09]

https://codereview.chromium.org/1128543002/diff/100001/chrome/browser/ui/webu...
File chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc (right):

https://codereview.chromium.org/1128543002/diff/100001/chrome/browser/ui/webu...
chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc:360: if (url.host()
== chrome::kChromeUIWebComponentTestHost)
How can we mitigate this being accessible outside of a testing environment?  I'm
concerned about the security implications of this infrastructure.

[michaelpg, 2015-05-14 19:06:31]

https://codereview.chromium.org/1128543002/diff/100001/chrome/browser/ui/webu...
File chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc (right):

https://codereview.chromium.org/1128543002/diff/100001/chrome/browser/ui/webu...
chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc:360: if (url.host()
== chrome::kChromeUIWebComponentTestHost)
On 2015/05/14 15:16:09, James Hawkins wrote:
> How can we mitigate this being accessible outside of a testing environment? 
I'm
> concerned about the security implications of this infrastructure.

We could put it behind a flag, but I don't think that's warranted. This is a
blank Web UI so it can't do anything more than other Web UI can do.

In a follow-up CL we'll add mocha.js to this UI. So separately, we should figure
out a way to only include mocha when needed for testing. That discussion is
here:
https://codereview.chromium.org/1124873002/diff/80001/chrome/browser/browser_...

[James Hawkins, 2015-05-15 18:00:28]

On 2015/05/14 19:06:31, michaelpg wrote:
>
https://codereview.chromium.org/1128543002/diff/100001/chrome/browser/ui/webu...
> File chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc (right):
> 
>
https://codereview.chromium.org/1128543002/diff/100001/chrome/browser/ui/webu...
> chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc:360: if
(url.host()
> == chrome::kChromeUIWebComponentTestHost)
> On 2015/05/14 15:16:09, James Hawkins wrote:
> > How can we mitigate this being accessible outside of a testing environment? 
> I'm
> > concerned about the security implications of this infrastructure.
> 
> We could put it behind a flag, but I don't think that's warranted. This is a
> blank Web UI so it can't do anything more than other Web UI can do.
> 
> In a follow-up CL we'll add mocha.js to this UI. So separately, we should
figure
> out a way to only include mocha when needed for testing. That discussion is
> here:
>
https://codereview.chromium.org/1124873002/diff/80001/chrome/browser/browser_...

There is probably an easier way to exclude these files from the prod build.  We
don't include test files; how does that happen?  I'm mostly concerned about
unknown security risks, so I think we should run this by Chrome security.  I'm
also not a fan of having this test code contribute to the binary size increase,
even though it's relatively small...death by a thousand cuts and whatnot.

[michaelpg, 2015-05-19 03:06:32]

On 2015/05/15 18:00:28, James Hawkins wrote:
> On 2015/05/14 19:06:31, michaelpg wrote:
> >
>
https://codereview.chromium.org/1128543002/diff/100001/chrome/browser/ui/webu...
> > File chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc (right):
> > 
> >
>
https://codereview.chromium.org/1128543002/diff/100001/chrome/browser/ui/webu...
> > chrome/browser/ui/webui/chrome_web_ui_controller_factory.cc:360: if
> (url.host()
> > == chrome::kChromeUIWebComponentTestHost)
> > On 2015/05/14 15:16:09, James Hawkins wrote:
> > > How can we mitigate this being accessible outside of a testing
environment? 
> > I'm
> > > concerned about the security implications of this infrastructure.
> > 
> > We could put it behind a flag, but I don't think that's warranted. This is a
> > blank Web UI so it can't do anything more than other Web UI can do.
> > 
> > In a follow-up CL we'll add mocha.js to this UI. So separately, we should
> figure
> > out a way to only include mocha when needed for testing. That discussion is
> > here:
> >
>
https://codereview.chromium.org/1124873002/diff/80001/chrome/browser/browser_...
> 
> There is probably an easier way to exclude these files from the prod build. 
We
> don't include test files; how does that happen?

I've figured out the right way to load Mocha files in browser_tests so they're
not part of the chrome binary. But for this CL specifically, we want the WebUI
in the chrome binary. We could exclude it from buildtype=Official, is that good
enough?

>  I'm mostly concerned about
> unknown security risks, so I think we should run this by Chrome security.

I'm happy to do that.

>  I'm
> also not a fan of having this test code contribute to the binary size
increase,
> even though it's relatively small...death by a thousand cuts and whatnot.

fair point. If we limit our testing to non-official builds we'd only increase
the size of non-"buildtype=Official" binaries.

This WebUI isn't strictly necessary. We could navigate to any chrome:// WebUI to
import the Polymer components to test. My original example went to
chrome://chrome-urls and set document.body.innerText=''. But that seems too
hacky, and IMO the cost of this CL is minor. I'm still open to suggestions
though -- we need something that makes sense across the board.