Implement Chrome Extension TabCapture API.

chrome/renderer/resources/extensions/tab_capture_custom_bindings.js

+// Copyright (c) 2012 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Custom bindings for the Tab Capture API.
+var chromeHidden = requireNative('chrome_hidden').GetChromeHidden();
+
+chromeHidden.registerCustomHook('tabCapture',
+                                function(bindingsAPI, extensionId) {
+  var apiFunctions = bindingsAPI.apiFunctions;
+
+  apiFunctions.setCustomCallback('capture',
+                                 function(name, request, response) {
+    if (response && request.callback) {
+      var callback = request.callback;
+      var successFunc = function(stream) {
+        callback(stream);
+      };
+      var errorFunc = function() {
+        callback(null);
+      };
+
+      var options = {};
+      options.video = response.videoConstraints;
+      options.audio = response.audioConstraints;
+
+      navigator.webkitGetUserMedia(options, successFunc, errorFunc);

[Aaron Boodman, 2012/10/16 04:19:27]

Silly question: Does the implementation of webKitGetUserMedia() check
TabCaptureRegistry? Otherwise it seems like people could bypass the permission
checks.

[justinlin, 2012/10/17 08:32:26]

I think you're right. Unfortunately, I've thought about it I don't see a clean
way to fix this yet. There isn't any easy way to access the registry or figure
out the script that called it after the webkit call. I've added the a
command-line flag to protect this a bit. Seeing as this would eventually be
callable from any web page, I'm not sure if it's worth trying to figure out a
hack for this. What do you think?

[Aaron Boodman, 2012/10/17 20:28:14]

If this is going to ever be exposed without the flag to users, then you'll have
to figure this out. I'm not totally clear on what the long-term plan is: are you
planning to eventually not have an extension API at all? If so, why do we need
it now again?

Assuming that the extension API is going to users, I think we should just figure
out how this should work now, rather than having the weird half-step with the
flag.

I see that there is a content::MediaObserver interface that Chrome uses. Can
this (or something similar) be extended to be used for permission checking? The
Chrome implementation would get the extension for the calling context, then make
sure that it has the tabCapture permission.

[justinlin, 2012/10/17 23:41:48]

My PM (markdavidscott@) might have a better answer for this, but putting it out
as an experimental extension API first is a good way to prototype and get
feedback about the feature before trying to propose it as a stardard WebKit API.
We also have a product that may make use of this feature.
Yea, I was brainstorming something similar, but it doesn't quiet feel right to
create another interface just for a permission check. Also, that's an observer
class, so feeding back data would be weird. I think I have a solution for this
that I'd like to submit separately. It's media-only changes:
http://codereview.chromium.org/11198044/
Basically fake a WebRTC permission check, and catch it when it's in the browser
to check the registry and allow/deny the request. There's still a problem with
the patch (for some reason, I'm getting the incorrect WebContents delegate when
the permission check comes from a background page), but I'll sort it out Today.
Minor note: it's actually hard for a user to use this anyway because they need
to figure out routing and render_process id's, which I don't think you can do
easily without being in chrome.

+    } else {
+      request.callback();
+    }
+    request.callback = null;
+  });
+});