Give the ChromeVox Panel an extension view type.

Give the ChromeVox Panel an extension view type.

The ChromeVox Panel is a native window that whose contents is a WebContents
displaying an extension page. Since r363368 the extension background isn't
able to communicate with this extension page because it doesn't have a view
type.

BUG=573023
Committed: https://crrev.com/5ba638da61040c7fb9c05b42b0ce4a90fa22157c
Cr-Commit-Position: refs/heads/master@{#368183}

[dmazzoni, 2015-12-29 23:15:54]

dmazzoni@chromium.org changed reviewers:
+ rdevlin.cronin@chromium.org, rob@robwu.nl

[Devlin, 2015-12-30 00:47:02]

lgtm.  You'll know best whether or not this warrants any kind of regression
test.

[robwu, 2015-12-30 09:47:05]

Is the ChromeVox panel really an extension panel? (i.e. equivalent to
chrome.windows.create({ type: 'panel', url: 'https://example.com'}); - if the
platform supports it (--enable-panels), this creates a window that floats above
other windows).

Setting ViewType to VIEW_TYPE_PANEL has other side effects, such as changing the
context menu:
https://chromium.googlesource.com/chromium/src/+/0d0a1e97194c6e9ea93c0808b0d1...

If ChromeVox' panel is not an extension panel, and it doesn't fit in any other
category, add a dummy type like VIEW_TYPE_EXTENSION_OTHER that means "This is an
extension view type, but it has no special meaning".

I looked around for similar code and found WebUILoginView::Init, which creates a
views::WebView and registers a extensions::ChromeExtensionWebContentsObserver,
but never sets a view type. If you decide to add a new view type, please set it
here as well. If not, I'll create a new issue and assign it to the owner of that
file.

[dmazzoni, 2016-01-04 18:17:01]

Please take another look since adding a new extension view type required
modifying a few more files. If it still looks good, feel free to cq+.

I'm working on a couple of related changes that will add more tests so I'll make
sure this gets test coverage soon.

On 2015/12/30 09:47:05, robwu wrote:
> Is the ChromeVox panel really an extension panel?

Nope. Didn't realize it had other side effects, thanks.

> If ChromeVox' panel is not an extension panel, and it doesn't fit in any other
> category, add a dummy type like VIEW_TYPE_EXTENSION_OTHER that means "This is
an
> extension view type, but it has no special meaning".

Sure, done.

> I looked around for similar code and found WebUILoginView::Init, which creates
a
> views::WebView and registers a extensions::ChromeExtensionWebContentsObserver,
> but never sets a view type. If you decide to add a new view type, please set
it
> here as well. If not, I'll create a new issue and assign it to the owner of
that
> file.

Done.

[robwu, 2016-01-04 18:26:53]

On 2016/01/04 18:17:01, dmazzoni wrote:
> Please take another look since adding a new extension view type required
> modifying a few more files. If it still looks good, feel free to cq+.
> 
> I'm working on a couple of related changes that will add more tests so I'll
make
> sure this gets test coverage soon.
> 
> On 2015/12/30 09:47:05, robwu wrote:
> > Is the ChromeVox panel really an extension panel?
> 
> Nope. Didn't realize it had other side effects, thanks.
> 
> > If ChromeVox' panel is not an extension panel, and it doesn't fit in any
other
> > category, add a dummy type like VIEW_TYPE_EXTENSION_OTHER that means "This
is
> an
> > extension view type, but it has no special meaning".
> 
> Sure, done.
> 
> > I looked around for similar code and found WebUILoginView::Init, which
creates
> a
> > views::WebView and registers a
extensions::ChromeExtensionWebContentsObserver,
> > but never sets a view type. If you decide to add a new view type, please set
> it
> > here as well. If not, I'll create a new issue and assign it to the owner of
> that
> > file.
> 
> Done.

Looks good overall, but you missed a few occurrences (I think that it will be
caught by tests).
- chrome/browser/extensions/api/developer_private/inspectable_views_finder.cc
- chrome/browser/extensions/chrome_extensions_browser_client.cc
- chrome/common/extensions/api/developer_private.idl

Just look at my CL where I introduced VIEW_TYPE_EXTENSION_GUEST and you'll find
all occurrences:
https://codereview.chromium.org/download/issue1413853005_420001.diff (Ctrl + F,
"EXTENSION_GUEST").

[Devlin, 2016-01-04 18:29:14]

D'oh.  I was just hoping that the view really was a panel.

https://codereview.chromium.org/1550983003/diff/20001/extensions/browser/proc...
File extensions/browser/process_manager.cc (right):

https://codereview.chromium.org/1550983003/diff/20001/extensions/browser/proc...
extensions/browser/process_manager.cc:171: case VIEW_TYPE_EXTENSION_OTHER:
Having a pseudo-dummy tag have keepalive makes me a bit nervous.  If ChromeVox
doesn't need this, I'd rather default to it not.

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
File extensions/common/view_type.h (right):

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
extensions/common/view_type.h:22: VIEW_TYPE_EXTENSION_OTHER,
Two thoughts:
- I think you're missing a few spots where this needs to be added - at least one
in the developerPrivate API.
- I dislike "other", even as a catch-all - because different catch-alls can have
significantly different requirements, and it might not be appropriate to lump
anything that isn't one of these into "OTHER".  I've been wondering for awhile
if we want something like "VIEW_TYPE_COMPONENT" for where we basically have an
extension view for a component of Chrome - I think VIRTUAL_KEYBOARD would also
fit in here.  Rob, what do you think?

[robwu, 2016-01-04 18:40:33]

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
File extensions/common/view_type.h (right):

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
extensions/common/view_type.h:22: VIEW_TYPE_EXTENSION_OTHER,
On 2016/01/04 18:29:14, Devlin wrote:
> Two thoughts:
> - I think you're missing a few spots where this needs to be added - at least
one
> in the developerPrivate API.
> - I dislike "other", even as a catch-all - because different catch-alls can
have
> significantly different requirements, and it might not be appropriate to lump
> anything that isn't one of these into "OTHER".  I've been wondering for awhile
> if we want something like "VIEW_TYPE_COMPONENT" for where we basically have an
> extension view for a component of Chrome - I think VIRTUAL_KEYBOARD would also
> fit in here.  Rob, what do you think?

I'm envisioning a catch-all without any special meaning. If you don't like
OTHER, then what do you think of VIEW_TYPE_EXTENSION_UNSPECIFIED ?

When this patch lands, I'll review the users of ViewType and finally add a
DCHECK_NE(viewType, VIEW_TYPE_INVALID) in ExtensionWebContentsObserver (this
avoids bugs like the one that I fixed in the patch that added
VIEW_TYPE_EXTENSION_GUEST in the future).

The keyboard should not be merged with this new type though, because it does
have special behavior w.r.t access to the webkitSpeechRecognition API, added in
https://codereview.chromium.org/24292004.

[dmazzoni, 2016-01-04 18:42:13]

https://codereview.chromium.org/1550983003/diff/20001/extensions/browser/proc...
File extensions/browser/process_manager.cc (right):

https://codereview.chromium.org/1550983003/diff/20001/extensions/browser/proc...
extensions/browser/process_manager.cc:171: case VIEW_TYPE_EXTENSION_OTHER:
On 2016/01/04 18:29:14, Devlin wrote:
> Having a pseudo-dummy tag have keepalive makes me a bit nervous.  If ChromeVox
> doesn't need this, I'd rather default to it not.

ChromeVox doesn't need this, so moved below.

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
File extensions/common/view_type.h (right):

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
extensions/common/view_type.h:22: VIEW_TYPE_EXTENSION_OTHER,
On 2016/01/04 18:29:14, Devlin wrote:
> Two thoughts:
> - I think you're missing a few spots where this needs to be added - at least
one
> in the developerPrivate API.

I added it to the developerPrivate API.

I did a search for EXTENSION_GUEST and I don't see anywhere else.

> - I dislike "other", even as a catch-all - because different catch-alls can
have
> significantly different requirements, and it might not be appropriate to lump
> anything that isn't one of these into "OTHER".  I've been wondering for awhile
> if we want something like "VIEW_TYPE_COMPONENT" for where we basically have an
> extension view for a component of Chrome - I think VIRTUAL_KEYBOARD would also
> fit in here.  Rob, what do you think?

That works for me. I do see some similarities with the virtual keyboard but I'm
not sure they have identical requirements.

[dmazzoni, 2016-01-05 17:07:38]

Any consensus on OTHER vs UNSPECIFIED vs COMPONENT?

[Devlin, 2016-01-05 17:45:46]

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
File extensions/common/view_type.h (right):

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
extensions/common/view_type.h:22: VIEW_TYPE_EXTENSION_OTHER,
On 2016/01/04 18:40:33, robwu wrote:
> On 2016/01/04 18:29:14, Devlin wrote:
> > Two thoughts:
> > - I think you're missing a few spots where this needs to be added - at least
> one
> > in the developerPrivate API.
> > - I dislike "other", even as a catch-all - because different catch-alls can
> have
> > significantly different requirements, and it might not be appropriate to
lump
> > anything that isn't one of these into "OTHER".  I've been wondering for
awhile
> > if we want something like "VIEW_TYPE_COMPONENT" for where we basically have
an
> > extension view for a component of Chrome - I think VIRTUAL_KEYBOARD would
also
> > fit in here.  Rob, what do you think?
> 
> I'm envisioning a catch-all without any special meaning. If you don't like
> OTHER, then what do you think of VIEW_TYPE_EXTENSION_UNSPECIFIED ?
> 
> When this patch lands, I'll review the users of ViewType and finally add a
> DCHECK_NE(viewType, VIEW_TYPE_INVALID) in ExtensionWebContentsObserver (this
> avoids bugs like the one that I fixed in the patch that added
> VIEW_TYPE_EXTENSION_GUEST in the future).
> 
> The keyboard should not be merged with this new type though, because it does
> have special behavior w.r.t access to the webkitSpeechRecognition API, added
in
> https://codereview.chromium.org/24292004.

The speech recognition is done for almost every view type, though -
      view_type == extensions::VIEW_TYPE_TAB_CONTENTS ||
      view_type == extensions::VIEW_TYPE_APP_WINDOW ||
      view_type == extensions::VIEW_TYPE_LAUNCHER_PAGE ||
      view_type == extensions::VIEW_TYPE_VIRTUAL_KEYBOARD ||
      view_type == extensions::VIEW_TYPE_EXTENSION_POPUP ||
      view_type == extensions::VIEW_TYPE_EXTENSION_BACKGROUND_PAGE
Seems like it'd probably be okay to add COMPONENT in that list in lieu of
VIRTUAL_KEYBOARD.

Having an UNSPECIFIED isn't as bad, but even then it's difficult to say what "no
special meaning" means.  All of these have some kind of special meaning (even if
that's just the generic "is an extension-y view"), so I think it might be easier
to draw the line with something else.  But I don't feel super strongly (although
I do like the idea of getting rid of VIRTUAL_KEYBOARD which always seems out of
place here, and not increasing the total count).

[robwu, 2016-01-05 22:48:22]

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
File extensions/common/view_type.h (right):

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
extensions/common/view_type.h:22: VIEW_TYPE_EXTENSION_OTHER,
On 2016/01/05 17:45:46, Devlin wrote:
> On 2016/01/04 18:40:33, robwu wrote:
> > On 2016/01/04 18:29:14, Devlin wrote:
> > > Two thoughts:
> > > - I think you're missing a few spots where this needs to be added - at
least
> > one
> > > in the developerPrivate API.
> > > - I dislike "other", even as a catch-all - because different catch-alls
can
> > have
> > > significantly different requirements, and it might not be appropriate to
> lump
> > > anything that isn't one of these into "OTHER".  I've been wondering for
> awhile
> > > if we want something like "VIEW_TYPE_COMPONENT" for where we basically
have
> an
> > > extension view for a component of Chrome - I think VIRTUAL_KEYBOARD would
> also
> > > fit in here.  Rob, what do you think?
> > 
> > I'm envisioning a catch-all without any special meaning. If you don't like
> > OTHER, then what do you think of VIEW_TYPE_EXTENSION_UNSPECIFIED ?
> > 
> > When this patch lands, I'll review the users of ViewType and finally add a
> > DCHECK_NE(viewType, VIEW_TYPE_INVALID) in ExtensionWebContentsObserver (this
> > avoids bugs like the one that I fixed in the patch that added
> > VIEW_TYPE_EXTENSION_GUEST in the future).
> > 
> > The keyboard should not be merged with this new type though, because it does
> > have special behavior w.r.t access to the webkitSpeechRecognition API, added
> in
> > https://codereview.chromium.org/24292004.
> 
> The speech recognition is done for almost every view type, though -
>       view_type == extensions::VIEW_TYPE_TAB_CONTENTS ||
>       view_type == extensions::VIEW_TYPE_APP_WINDOW ||
>       view_type == extensions::VIEW_TYPE_LAUNCHER_PAGE ||
>       view_type == extensions::VIEW_TYPE_VIRTUAL_KEYBOARD ||
>       view_type == extensions::VIEW_TYPE_EXTENSION_POPUP ||
>       view_type == extensions::VIEW_TYPE_EXTENSION_BACKGROUND_PAGE
> Seems like it'd probably be okay to add COMPONENT in that list in lieu of
> VIRTUAL_KEYBOARD.

Right. I have no objections against merging the two types any more.


> Having an UNSPECIFIED isn't as bad, but even then it's difficult to say what
"no
> special meaning" means.  All of these have some kind of special meaning (even
if
> that's just the generic "is an extension-y view"), so I think it might be
easier
> to draw the line with something else.  But I don't feel super strongly
(although
> I do like the idea of getting rid of VIRTUAL_KEYBOARD which always seems out
of
> place here, and not increasing the total count).

I favor OTHER over COMPONENT because COMPONENT is too specific and ambiguous
(component extension? browser component?) and can therefore not be used to tag
detached WebContents.

[Devlin, 2016-01-05 23:00:49]

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
File extensions/common/view_type.h (right):

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
extensions/common/view_type.h:22: VIEW_TYPE_EXTENSION_OTHER,
On 2016/01/05 22:48:22, robwu wrote:
> On 2016/01/05 17:45:46, Devlin wrote:
> > On 2016/01/04 18:40:33, robwu wrote:
> > > On 2016/01/04 18:29:14, Devlin wrote:
> > > > Two thoughts:
> > > > - I think you're missing a few spots where this needs to be added - at
> least
> > > one
> > > > in the developerPrivate API.
> > > > - I dislike "other", even as a catch-all - because different catch-alls
> can
> > > have
> > > > significantly different requirements, and it might not be appropriate to
> > lump
> > > > anything that isn't one of these into "OTHER".  I've been wondering for
> > awhile
> > > > if we want something like "VIEW_TYPE_COMPONENT" for where we basically
> have
> > an
> > > > extension view for a component of Chrome - I think VIRTUAL_KEYBOARD
would
> > also
> > > > fit in here.  Rob, what do you think?
> > > 
> > > I'm envisioning a catch-all without any special meaning. If you don't like
> > > OTHER, then what do you think of VIEW_TYPE_EXTENSION_UNSPECIFIED ?
> > > 
> > > When this patch lands, I'll review the users of ViewType and finally add a
> > > DCHECK_NE(viewType, VIEW_TYPE_INVALID) in ExtensionWebContentsObserver
(this
> > > avoids bugs like the one that I fixed in the patch that added
> > > VIEW_TYPE_EXTENSION_GUEST in the future).
> > > 
> > > The keyboard should not be merged with this new type though, because it
does
> > > have special behavior w.r.t access to the webkitSpeechRecognition API,
added
> > in
> > > https://codereview.chromium.org/24292004.
> > 
> > The speech recognition is done for almost every view type, though -
> >       view_type == extensions::VIEW_TYPE_TAB_CONTENTS ||
> >       view_type == extensions::VIEW_TYPE_APP_WINDOW ||
> >       view_type == extensions::VIEW_TYPE_LAUNCHER_PAGE ||
> >       view_type == extensions::VIEW_TYPE_VIRTUAL_KEYBOARD ||
> >       view_type == extensions::VIEW_TYPE_EXTENSION_POPUP ||
> >       view_type == extensions::VIEW_TYPE_EXTENSION_BACKGROUND_PAGE
> > Seems like it'd probably be okay to add COMPONENT in that list in lieu of
> > VIRTUAL_KEYBOARD.
> 
> Right. I have no objections against merging the two types any more.
> 
> 
> > Having an UNSPECIFIED isn't as bad, but even then it's difficult to say what
> "no
> > special meaning" means.  All of these have some kind of special meaning
(even
> if
> > that's just the generic "is an extension-y view"), so I think it might be
> easier
> > to draw the line with something else.  But I don't feel super strongly
> (although
> > I do like the idea of getting rid of VIRTUAL_KEYBOARD which always seems out
> of
> > place here, and not increasing the total count).
> 
> I favor OTHER over COMPONENT because COMPONENT is too specific and ambiguous
> (component extension? browser component?) and can therefore not be used to tag
> detached WebContents.

What do you mean by "detached WebContents"?  The specificity of COMPONENT is why
I prefer it over OTHER - we shouldn't have a view type that is unspecified. 
COMPONENT would be reserved for component pieces (like ChromeVox,
VirtualKeyboard, etc).

[robwu, 2016-01-05 23:05:03]

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
File extensions/common/view_type.h (right):

https://codereview.chromium.org/1550983003/diff/20001/extensions/common/view_...
extensions/common/view_type.h:22: VIEW_TYPE_EXTENSION_OTHER,
On 2016/01/05 23:00:49, Devlin wrote:
> On 2016/01/05 22:48:22, robwu wrote:
> > On 2016/01/05 17:45:46, Devlin wrote:
> > > On 2016/01/04 18:40:33, robwu wrote:
> > > > On 2016/01/04 18:29:14, Devlin wrote:
> > > > > Two thoughts:
> > > > > - I think you're missing a few spots where this needs to be added - at
> > least
> > > > one
> > > > > in the developerPrivate API.
> > > > > - I dislike "other", even as a catch-all - because different
catch-alls
> > can
> > > > have
> > > > > significantly different requirements, and it might not be appropriate
to
> > > lump
> > > > > anything that isn't one of these into "OTHER".  I've been wondering
for
> > > awhile
> > > > > if we want something like "VIEW_TYPE_COMPONENT" for where we basically
> > have
> > > an
> > > > > extension view for a component of Chrome - I think VIRTUAL_KEYBOARD
> would
> > > also
> > > > > fit in here.  Rob, what do you think?
> > > > 
> > > > I'm envisioning a catch-all without any special meaning. If you don't
like
> > > > OTHER, then what do you think of VIEW_TYPE_EXTENSION_UNSPECIFIED ?
> > > > 
> > > > When this patch lands, I'll review the users of ViewType and finally add
a
> > > > DCHECK_NE(viewType, VIEW_TYPE_INVALID) in ExtensionWebContentsObserver
> (this
> > > > avoids bugs like the one that I fixed in the patch that added
> > > > VIEW_TYPE_EXTENSION_GUEST in the future).
> > > > 
> > > > The keyboard should not be merged with this new type though, because it
> does
> > > > have special behavior w.r.t access to the webkitSpeechRecognition API,
> added
> > > in
> > > > https://codereview.chromium.org/24292004.
> > > 
> > > The speech recognition is done for almost every view type, though -
> > >       view_type == extensions::VIEW_TYPE_TAB_CONTENTS ||
> > >       view_type == extensions::VIEW_TYPE_APP_WINDOW ||
> > >       view_type == extensions::VIEW_TYPE_LAUNCHER_PAGE ||
> > >       view_type == extensions::VIEW_TYPE_VIRTUAL_KEYBOARD ||
> > >       view_type == extensions::VIEW_TYPE_EXTENSION_POPUP ||
> > >       view_type == extensions::VIEW_TYPE_EXTENSION_BACKGROUND_PAGE
> > > Seems like it'd probably be okay to add COMPONENT in that list in lieu of
> > > VIRTUAL_KEYBOARD.
> > 
> > Right. I have no objections against merging the two types any more.
> > 
> > 
> > > Having an UNSPECIFIED isn't as bad, but even then it's difficult to say
what
> > "no
> > > special meaning" means.  All of these have some kind of special meaning
> (even
> > if
> > > that's just the generic "is an extension-y view"), so I think it might be
> > easier
> > > to draw the line with something else.  But I don't feel super strongly
> > (although
> > > I do like the idea of getting rid of VIRTUAL_KEYBOARD which always seems
out
> > of
> > > place here, and not increasing the total count).
> > 
> > I favor OTHER over COMPONENT because COMPONENT is too specific and ambiguous
> > (component extension? browser component?) and can therefore not be used to
tag
> > detached WebContents.
> 
> What do you mean by "detached WebContents"?  The specificity of COMPONENT is
why
> I prefer it over OTHER - we shouldn't have a view type that is unspecified. 
> COMPONENT would be reserved for component pieces (like ChromeVox,
> VirtualKeyboard, etc).

This is a detached WebContents (=not associated with any browser):
https://chromium.googlesource.com/chromium/src/+/7c802f0c389c951f5e6103af448d...

[Devlin, 2016-01-07 19:40:08]

On 2016/01/05 23:05:03, robwu wrote:
> 
> This is a detached WebContents (=not associated with any browser):
>
https://chromium.googlesource.com/chromium/src/+/7c802f0c389c951f5e6103af448d...

If it has custom built-in support from Chrome, I'd argue that it's component -
i.e., it's for a specific piece of Chrome(OS) and is not available to extensions
on the whole.

All that said, let's not block this on bikeshedding, because getting that
CHECK_NE(VIEW_TYPE_INVALID) would be really nice.  Rob, if you have another
example where component doesn't work, then let's go with UNSPECIFIED. 
Otherwise, I'd still opt for COMPONENT.  Let's combine it and VK and add a
comment that it's for custom parts of chrome where the other view types aren't
accurate.

After that, lgtm.

[dmazzoni, 2016-01-07 20:19:42]

Replaced with VIEW_TYPE_COMPONENT. I'll commit this if I don't hear any
objections.

[robwu, 2016-01-07 20:25:37]

On 2016/01/07 20:19:42, dmazzoni wrote:
> Replaced with VIEW_TYPE_COMPONENT. I'll commit this if I don't hear any
> objections.

The comment at VIEW_TYPE_COMPONENT in view_type.h is great.
LGTM.

[dmazzoni, 2016-01-07 21:09:55]

The CQ bit was checked by dmazzoni@chromium.org

[dmazzoni, 2016-01-07 21:09:56]

The patchset sent to the CQ was uploaded after l-g-t-m from
rdevlin.cronin@chromium.org
Link to the patchset: https://codereview.chromium.org/1550983003/#ps60001
(title: "VIEW_TYPE_COMPONENT")

[commit-bot: I haz the power, 2016-01-07 21:10:26]

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

[commit-bot: I haz the power, 2016-01-07 21:20:46]

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

[commit-bot: I haz the power, 2016-01-07 21:20:46]

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

[dmazzoni, 2016-01-07 21:44:22]

dmazzoni@chromium.org changed reviewers:
+ oshima@chromium.org

[dmazzoni, 2016-01-07 21:44:22]

+oshima for:
chrome/browser/chromeos
chrome/browser/ui/ash

[oshima, 2016-01-07 22:14:58]

lgtm

[dmazzoni, 2016-01-07 22:52:09]

The CQ bit was checked by dmazzoni@chromium.org

[commit-bot: I haz the power, 2016-01-07 22:53:38]

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

[commit-bot: I haz the power, 2016-01-07 22:59:01]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-01-07 22:59:52]

Description was changed from

==========
Give the ChromeVox Panel an extension view type.

The ChromeVox Panel is a native window that whose contents is a WebContents
displaying an extension page. Since r363368 the extension background isn't
able to communicate with this extension page because it doesn't have a view
type.

BUG=573023
==========

to

==========
Give the ChromeVox Panel an extension view type.

The ChromeVox Panel is a native window that whose contents is a WebContents
displaying an extension page. Since r363368 the extension background isn't
able to communicate with this extension page because it doesn't have a view
type.

BUG=573023

Committed: https://crrev.com/5ba638da61040c7fb9c05b42b0ce4a90fa22157c
Cr-Commit-Position: refs/heads/master@{#368183}
==========

[commit-bot: I haz the power, 2016-01-07 22:59:53]

Patchset 4 (id:??) landed as
https://crrev.com/5ba638da61040c7fb9c05b42b0ce4a90fa22157c
Cr-Commit-Position: refs/heads/master@{#368183}