Hook up insecure content warnings for http webVR presentation.

Hook up insecure content warnings for http webVR presentation.

This CL was partially written by cjgrant@

BUG=713938
Review-Url: https://codereview.chromium.org/2834543006
Cr-Commit-Position: refs/heads/master@{#466658}
Committed: https://chromium.googlesource.com/chromium/src/+/7c6a3e3baf6ad88f8a28ac4ef7d46664d95c9e74

[mthiesse, 2017-04-21 00:12:52]

mthiesse@chromium.org changed reviewers:
+ acondor@google.com, cjgrant@chromium.org

[mthiesse, 2017-04-21 00:12:52]

PTAL

[mthiesse, 2017-04-21 00:13:18]

Note that this diff is based on https://codereview.chromium.org/2817663003/

[mthiesse, 2017-04-21 00:15:15]

Description was changed from

==========
Hook up insecure content warnings for http webVR presentation.

BUG=713938
==========

to

==========
Hook up insecure content warnings for http webVR presentation.

This CL was partially written by cjgrant@

BUG=713938
==========

[cjgrant, 2017-04-21 14:30:14]

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textured_element.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:30: size = {size.x(), y, 1};
This is a little interesting in that the scene manager could set the size, and
have it trampled here, right?  It makes sense though.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:51:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
Aren't these the same properties being set at render time?

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textured_element.h (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.h:15: class UITexture;
Should we rename this UiTexture to match UiElement?

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.h:19: explicit
TexturedElement(int preferred_width);
An element width is in meters; I think the parameter should be documented here.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.h:35: unsigned int
texture_handle_;
Possibly GLuint for clarity?  This is what glGenTextures() returns.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File
chrome/browser/android/vr_shell/textures/insecure_content_transient_texture.cc
(right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textures/insecure_content_transient_texture.cc:56:
DCHECK(size_.height() <= max_height);
DCHECK_LE()

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textures/ui_texture.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textures/ui_texture.cc:35:
gfx_canvas.DrawColor(0x00000000);
SK_ColorTRANSPARENT

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/ui_scene.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/ui_scene.cc:210: for (const auto& element :
ui_elements_) {
This is another situation where the const should be breaking compilation but
isn't.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/vr_shell_gl.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_gl.cc:297: scene_->OnGLInitialized();
So just my opinion here, but I really don't like that scene needs this, and by
proxy, that elements need separate construct and initialize steps.  I think this
would be much cleaner if:
- Only the scene manager is aware of GL-isms (which is clear since it needs to
construct GL-based elements).
- The scene stays unaware of element details, and focuses on scene graph type
stuff.
- VrShellGl's constructor accepted a callback parameter, OnGlInitiaized.
- The GL thread binds a callback to SceneManager::OnGlInitialized() and gives it
to the GL thread.  It could use this for other things in the future if needed.
- Scene manager creates all elements when that callback fires; the scene doesn't
know about GL, and elements are created in one step.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_gl.cc:1025:
vr_shell_renderer_->GetSkiaQuadRenderer()->Flush();
This isn't healthy IMO.  Longer-term, vr_shell_renderer_->Flush() would be
better.  It ought to be aware of what it's renderers are up to under the hood,
rather than this module.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/vr_shell_renderer.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_renderer.cc:423:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
I recall Aldo saying we didn't need these values set here, but I could be wrong.
 Aldo?

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_renderer.cc:798:
skia_quad_renderer_->Flush();
I'm not sure this approach is much better than before.  A user of the renderer
could hold a pointer to their desired renderer type to save fetching it every
time.  Another option is to have VrShellRenderer track the last drawn type, and
if the type changes, have VrShellRenderer ratchet through all renderers and
flush each (if supported).  Can chat offline, and it doesn't matter much for
this particular CL.

[acondor_, 2017-04-21 15:04:24]

2 general comments:
- textures folder contains all classes related to textures, but ui_elements
folder contains only the specializations. We should do the same for both
folders, but I'm not sure which one is the correct approach.
- I don't quite like the name SkiaQuadRenderer, which is different from the
TexturedQuadRenderer. They both render textures, but the actual difference in
the shaders is whether they render an internal or external texture.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textured_element.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:22: size_ =
GetTexture()->GetPreferredTextureSize(preferred_width_);
I would use the word Maximum instead of Preferred, because that will be the
surface limit.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:28: gfx::SizeF actual_size =
GetTexture()->GetActualSize();
drawn_size maybe?

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:30: size = {size.x(), y, 1};
Are we sure we want to fix X coordinate globally? In the permanent warning we
should fix the height and in the transient the width, in order to maintain the
same font size across languages.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:51:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
They are ok here, once per the whole execution and not per frame. If they are in
the renderer too, we should remove them.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textured_element.h (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.h:34: gfx::Size size_;
texture_size_ so that it's not confused with UIElement's size.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File
chrome/browser/android/vr_shell/textures/insecure_content_permanent_texture.h
(right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textures/insecure_content_permanent_texture.h:17:
gfx::SizeF GetActualSize() const override;
GetDrawnSize?

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/vr_shell_renderer.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_renderer.cc:124: return OEIE_SHADER(
No need for OEIE

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_renderer.cc:423:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
On 2017/04/21 14:30:13, cjgrant wrote:
> I recall Aldo saying we didn't need these values set here, but I could be
wrong.
>  Aldo?

We don't :)

[mthiesse, 2017-04-21 15:05:12]

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textured_element.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:30: size = {size.x(), y, 1};
On 2017/04/21 14:30:13, cjgrant wrote:
> This is a little interesting in that the scene manager could set the size, and
> have it trampled here, right?  It makes sense though.

Yeah, I want to refactor this in the future. We should be able to measure the
text before we actually render it, and determine what the elements size will be
before initializing it, meaning we don't have to override it later because the
size won't change.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:51:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
On 2017/04/21 14:30:13, cjgrant wrote:
> Aren't these the same properties being set at render time?

yes. I didn't write this part so I'm not actually sure these are necessary, but
I think they are for glTexImage2D?

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textured_element.h (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.h:15: class UITexture;
On 2017/04/21 14:30:13, cjgrant wrote:
> Should we rename this UiTexture to match UiElement?

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.h:19: explicit
TexturedElement(int preferred_width);
On 2017/04/21 14:30:13, cjgrant wrote:
> An element width is in meters; I think the parameter should be documented
here.

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.h:35: unsigned int
texture_handle_;
On 2017/04/21 14:30:13, cjgrant wrote:
> Possibly GLuint for clarity?  This is what glGenTextures() returns.

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File
chrome/browser/android/vr_shell/textures/insecure_content_transient_texture.cc
(right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textures/insecure_content_transient_texture.cc:56:
DCHECK(size_.height() <= max_height);
On 2017/04/21 14:30:13, cjgrant wrote:
> DCHECK_LE()

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textures/ui_texture.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textures/ui_texture.cc:35:
gfx_canvas.DrawColor(0x00000000);
On 2017/04/21 14:30:13, cjgrant wrote:
> SK_ColorTRANSPARENT

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/ui_scene.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/ui_scene.cc:210: for (const auto& element :
ui_elements_) {
On 2017/04/21 14:30:13, cjgrant wrote:
> This is another situation where the const should be breaking compilation but
> isn't.

No, because the unique_ptr is constant, but -> doesn't return a const pointer,
even when the unique_ptr is const.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/vr_shell_gl.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_gl.cc:297: scene_->OnGLInitialized();
On 2017/04/21 14:30:13, cjgrant wrote:
> So just my opinion here, but I really don't like that scene needs this, and by
> proxy, that elements need separate construct and initialize steps.  I think
this
> would be much cleaner if:
> - Only the scene manager is aware of GL-isms (which is clear since it needs to
> construct GL-based elements).
> - The scene stays unaware of element details, and focuses on scene graph type
> stuff.
> - VrShellGl's constructor accepted a callback parameter, OnGlInitiaized.
> - The GL thread binds a callback to SceneManager::OnGlInitialized() and gives
it
> to the GL thread.  It could use this for other things in the future if needed.
> - Scene manager creates all elements when that callback fires; the scene
doesn't
> know about GL, and elements are created in one step.
> 

Agreed, but I avoided doing that for now because this is simpler in the short
term. We should fix this in a followup we don't merge back to M59.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_gl.cc:1025:
vr_shell_renderer_->GetSkiaQuadRenderer()->Flush();
On 2017/04/21 14:30:13, cjgrant wrote:
> This isn't healthy IMO.  Longer-term, vr_shell_renderer_->Flush() would be
> better.  It ought to be aware of what it's renderers are up to under the hood,
> rather than this module.

Changed to vr_shell_renderer_->Flush(); for now. Longer term we need some larger
refactoring here.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/vr_shell_renderer.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_renderer.cc:798:
skia_quad_renderer_->Flush();
On 2017/04/21 14:30:13, cjgrant wrote:
> I'm not sure this approach is much better than before.  A user of the renderer
> could hold a pointer to their desired renderer type to save fetching it every
> time.  Another option is to have VrShellRenderer track the last drawn type,
and
> if the type changes, have VrShellRenderer ratchet through all renderers and
> flush each (if supported).  Can chat offline, and it doesn't matter much for
> this particular CL.

Yeah, right now we don't hold onto pointers, and we could return const
references to ensure that, but we should rethink this whole class and do some
refactoring for M60 instead.

[cjgrant, 2017-04-21 15:19:33]

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/ui_scene.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/ui_scene.cc:210: for (const auto& element :
ui_elements_) {
On 2017/04/21 15:05:12, mthiesse wrote:
> On 2017/04/21 14:30:13, cjgrant wrote:
> > This is another situation where the const should be breaking compilation but
> > isn't.
> 
> No, because the unique_ptr is constant, but -> doesn't return a const pointer,
> even when the unique_ptr is const.

Right.  I mean that we shouldn't bother with the const here, as it looks
confusing.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/vr_shell_gl.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_gl.cc:297: scene_->OnGLInitialized();
On 2017/04/21 15:05:12, mthiesse wrote:
> On 2017/04/21 14:30:13, cjgrant wrote:
> > So just my opinion here, but I really don't like that scene needs this, and
by
> > proxy, that elements need separate construct and initialize steps.  I think
> this
> > would be much cleaner if:
> > - Only the scene manager is aware of GL-isms (which is clear since it needs
to
> > construct GL-based elements).
> > - The scene stays unaware of element details, and focuses on scene graph
type
> > stuff.
> > - VrShellGl's constructor accepted a callback parameter, OnGlInitiaized.
> > - The GL thread binds a callback to SceneManager::OnGlInitialized() and
gives
> it
> > to the GL thread.  It could use this for other things in the future if
needed.
> > - Scene manager creates all elements when that callback fires; the scene
> doesn't
> > know about GL, and elements are created in one step.
> > 
> 
> Agreed, but I avoided doing that for now because this is simpler in the short
> term. We should fix this in a followup we don't merge back to M59.

Mind making a (single or separate) bug for renderer flush cleanup and GL init
cleanup?

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/vr_shell_renderer.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_renderer.cc:798:
skia_quad_renderer_->Flush();
On 2017/04/21 15:05:12, mthiesse wrote:
> On 2017/04/21 14:30:13, cjgrant wrote:
> > I'm not sure this approach is much better than before.  A user of the
renderer
> > could hold a pointer to their desired renderer type to save fetching it
every
> > time.  Another option is to have VrShellRenderer track the last drawn type,
> and
> > if the type changes, have VrShellRenderer ratchet through all renderers and
> > flush each (if supported).  Can chat offline, and it doesn't matter much for
> > this particular CL.
> 
> Yeah, right now we don't hold onto pointers, and we could return const
> references to ensure that, but we should rethink this whole class and do some
> refactoring for M60 instead.

Agreed.

https://codereview.chromium.org/2834543006/diff/60001/chrome/browser/android/...
File
chrome/browser/android/vr_shell/textures/insecure_content_permanent_texture.h
(left):

https://codereview.chromium.org/2834543006/diff/60001/chrome/browser/android/...
chrome/browser/android/vr_shell/textures/insecure_content_permanent_texture.h:12:
class InsecureContentPermanentTexture : public UITexture {
optional nit: We might want to rename these classes to match
transient_security_warning.h and permanent_security_warning.h.

ie. transient_security_warning_texture.h seems much more clear than
insecure_content_transient_texture.h (where the texture sounds transient).

Lets rename ALL the things.

[mthiesse, 2017-04-21 17:17:30]

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textured_element.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:22: size_ =
GetTexture()->GetPreferredTextureSize(preferred_width_);
On 2017/04/21 15:04:23, acondor wrote:
> I would use the word Maximum instead of Preferred, because that will be the
> surface limit.

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:28: gfx::SizeF actual_size =
GetTexture()->GetActualSize();
On 2017/04/21 15:04:23, acondor wrote:
> drawn_size maybe?

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.cc:51:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
On 2017/04/21 15:04:23, acondor wrote:
> They are ok here, once per the whole execution and not per frame. If they are
in
> the renderer too, we should remove them.

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/textured_element.h (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textured_element.h:34: gfx::Size size_;
On 2017/04/21 15:04:23, acondor wrote:
> texture_size_ so that it's not confused with UIElement's size.

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File
chrome/browser/android/vr_shell/textures/insecure_content_permanent_texture.h
(right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/textures/insecure_content_permanent_texture.h:17:
gfx::SizeF GetActualSize() const override;
On 2017/04/21 15:04:23, acondor wrote:
> GetDrawnSize?

Done.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/ui_scene.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/ui_scene.cc:210: for (const auto& element :
ui_elements_) {
On 2017/04/21 15:19:33, cjgrant wrote:
> On 2017/04/21 15:05:12, mthiesse wrote:
> > On 2017/04/21 14:30:13, cjgrant wrote:
> > > This is another situation where the const should be breaking compilation
but
> > > isn't.
> > 
> > No, because the unique_ptr is constant, but -> doesn't return a const
pointer,
> > even when the unique_ptr is const.
> 
> Right.  I mean that we shouldn't bother with the const here, as it looks
> confusing.

Fixed by getting rid of auto so it's not confusing.

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
File chrome/browser/android/vr_shell/vr_shell_renderer.cc (right):

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_renderer.cc:124: return OEIE_SHADER(
On 2017/04/21 15:04:23, acondor wrote:
> No need for OEIE

Good catch

https://codereview.chromium.org/2834543006/diff/20001/chrome/browser/android/...
chrome/browser/android/vr_shell/vr_shell_renderer.cc:423:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE);
On 2017/04/21 15:04:23, acondor wrote:
> On 2017/04/21 14:30:13, cjgrant wrote:
> > I recall Aldo saying we didn't need these values set here, but I could be
> wrong.
> >  Aldo?
> 
> We don't :)

Done.

https://codereview.chromium.org/2834543006/diff/60001/chrome/browser/android/...
File
chrome/browser/android/vr_shell/textures/insecure_content_permanent_texture.h
(left):

https://codereview.chromium.org/2834543006/diff/60001/chrome/browser/android/...
chrome/browser/android/vr_shell/textures/insecure_content_permanent_texture.h:12:
class InsecureContentPermanentTexture : public UITexture {
On 2017/04/21 15:19:33, cjgrant wrote:
> optional nit: We might want to rename these classes to match
> transient_security_warning.h and permanent_security_warning.h.
> 
> ie. transient_security_warning_texture.h seems much more clear than
> insecure_content_transient_texture.h (where the texture sounds transient).
> 
> Lets rename ALL the things.

Let's do this in a followup to avoid merge conflicts for now.

[acondor_, 2017-04-21 19:01:56]

lgtm

LGTM

[cjgrant, 2017-04-21 19:02:22]

lgtm

[mthiesse, 2017-04-22 15:19:09]

The CQ bit was checked by mthiesse@chromium.org

[mthiesse, 2017-04-22 15:19:09]

The patchset sent to the CQ was uploaded after l-g-t-m from acondor@google.com,
cjgrant@chromium.org
Link to the patchset: https://codereview.chromium.org/2834543006/#ps100001
(title: "rebase")

[commit-bot: I haz the power, 2017-04-22 15:19:24]

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-04-22 16:57:56]

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

[commit-bot: I haz the power, 2017-04-22 16:57:57]

Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)

[mthiesse, 2017-04-24 15:35:56]

The CQ bit was checked by mthiesse@chromium.org

[mthiesse, 2017-04-24 15:35:57]

The patchset sent to the CQ was uploaded after l-g-t-m from acondor@google.com,
cjgrant@chromium.org
Link to the patchset: https://codereview.chromium.org/2834543006/#ps120001
(title: "rebase")

[commit-bot: I haz the power, 2017-04-24 15:36:38]

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-04-24 16:40:26]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1493048156756450,
"parent_rev": "68d790c9b65a19be13458e8e81154faa85e38e61", "commit_rev":
"f04d7e04398b2229d89d31a5e1a0c0e206fb8e91"}

[commit-bot: I haz the power, 2017-04-24 16:40:41]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1493048156756450,
"parent_rev": "bd3a51d334482c11da8b0df38d2c077bfb331fa5", "commit_rev":
"7c6a3e3baf6ad88f8a28ac4ef7d46664d95c9e74"}

[commit-bot: I haz the power, 2017-04-24 16:40:55]

Description was changed from

==========
Hook up insecure content warnings for http webVR presentation.

This CL was partially written by cjgrant@

BUG=713938
==========

to

==========
Hook up insecure content warnings for http webVR presentation.

This CL was partially written by cjgrant@

BUG=713938

Review-Url: https://codereview.chromium.org/2834543006
Cr-Commit-Position: refs/heads/master@{#466658}
Committed:
https://chromium.googlesource.com/chromium/src/+/7c6a3e3baf6ad88f8a28ac4ef7d4...
==========

[commit-bot: I haz the power, 2017-04-24 16:40:56]

Committed patchset #7 (id:120001) as
https://chromium.googlesource.com/chromium/src/+/7c6a3e3baf6ad88f8a28ac4ef7d4...