Give the ChromeVox Panel an extension view type.

extensions/common/view_type.h

Index: extensions/common/view_type.h
diff --git a/extensions/common/view_type.h b/extensions/common/view_type.h
index bbe498dbb63baa969ceaa7ea764a252bcf449e5b..b4b923b110aa6f2a27a21530a413bad164595caa 100644
--- a/extensions/common/view_type.h
+++ b/extensions/common/view_type.h
@@ -19,6 +19,7 @@ enum ViewType {
   VIEW_TYPE_EXTENSION_BACKGROUND_PAGE,
   VIEW_TYPE_EXTENSION_DIALOG,
   VIEW_TYPE_EXTENSION_GUEST,
+  VIEW_TYPE_EXTENSION_OTHER,

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

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]

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]

I added it to the developerPrivate API.

I did a search for EXTENSION_GUEST and I don't see anywhere else.
That works for me. I do see some similarities with the virtual keyboard but I'm
not sure they have identical requirements.

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

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]

Right. I have no objections against merging the two types any more.
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]

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]

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

   VIEW_TYPE_EXTENSION_POPUP,
   VIEW_TYPE_LAUNCHER_PAGE,
   VIEW_TYPE_PANEL,