Removal of getUserMedia() on insecure origins

Source/modules/mediastream/NavigatorMediaStream.cpp

Index: Source/modules/mediastream/NavigatorMediaStream.cpp
diff --git a/Source/modules/mediastream/NavigatorMediaStream.cpp b/Source/modules/mediastream/NavigatorMediaStream.cpp
index 54fd5c0f5693162c8c2e5cbf9af0eaae1314155a..fb81b87347e0d5d3c0e6ed456bfc17ca77ed6369 100644
--- a/Source/modules/mediastream/NavigatorMediaStream.cpp
+++ b/Source/modules/mediastream/NavigatorMediaStream.cpp
@@ -67,10 +67,8 @@ void NavigatorMediaStream::webkitGetUserMedia(Navigator& navigator, const Dictio
     } else {
         UseCounter::countDeprecation(navigator.frame(), UseCounter::GetUserMediaInsecureOrigin);
         OriginsUsingFeatures::countAnyWorld(*navigator.frame()->document(), OriginsUsingFeatures::Feature::GetUserMediaInsecureOrigin);
-        if (navigator.frame()->settings()->strictPowerfulFeatureRestrictions()) {
-            exceptionState.throwSecurityError(ExceptionMessages::failedToExecute("webkitGetUserMedia", "Navigator", errorMessage));
-            return;
-        }
+        exceptionState.throwSecurityError(errorMessage);

[Mike West, 2015/08/18 00:28:38]

Why throw? Why not go through the error callback like the other rejection types?

[philipj_slow, 2015/08/18 08:35:10]

Looking at
http://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevices-get...
I don't see it described how the rejection should happen. Is there an open spec
bug for that? Even if it's an optional step, it's still better to have it in the
main spec than in a supplement spec or something.

[jww, 2015/08/18 16:27:12]

Looking at https://w3c.github.io/mediacapture-main/getusermedia.html#methods-4,
it seems to me that this is rather similar to the "Permission Failure" and
should be a promise rejection (which, for now, would remain an error callback I
believe). This also maps to what slightlyoff@ said to me in conversation
yesterday.

However, it's not clear to me what type of error the callback should be made
with. Should we just make up a new one, and file a bug with the spec suggesting
that a new one is needed? Or should we just reuse "PermissionDeniedError" for
now?

[philipj_slow, 2015/08/19 12:26:43]

Oh, I didn't see the "Permission Failure" bit in the spec. It's pretty clear, it
says to use a DOMException of the SecurityError flavor.

[philipj_slow, 2015/08/19 12:39:24]

Oh, I see the difficulty now, this is webkitGetUserMedia() which doesn't return
a promise. The only guidance would be what the spec used to say before
promisification:
https://github.com/w3c/mediacapture-main/commit/f6c4e9085568a81d5e9d36ca32eea...

And that was:

10. Optionally, e.g., based on a previously-established user preference, for
security reasons, or due to platform limitations, jump to the step labeled
Permission Failure below.
15. Permission Failure: Let error be a new MediaStreamError object whose name
attribute has the value PermissionDeniedError and jump to the step labeled Error
Task below.
19. Error Task: Queue a task to invoke errorCallback with error as its argument.

So using the error callback seems good, it also slightly increases the chances
of the problem being handled correctly (or like a user rejection), I think.

[jww, 2015/08/19 17:10:33]

Okay, I've modified to call the error callback with a PermissionDenied error.

+        return;
     }
 
     UserMediaRequest* request = UserMediaRequest::create(navigator.frame()->document(), userMedia, options, successCallback, errorCallback, exceptionState);