Removal of getUserMedia() on insecure origins

Source/modules/mediastream/NavigatorMediaStream.cpp

 /*
  *  Copyright (C) 2000 Harri Porten (porten@kde.org)
  *  Copyright (c) 2000 Daniel Molkentin (molkentin@kde.org)
  *  Copyright (c) 2000 Stefan Schimanski (schimmi@kde.org)
  *  Copyright (C) 2003, 2004, 2005, 2006 Apple Computer, Inc.
  *  Copyright (C) 2008 Nokia Corporation and/or its subsidiary(-ies)
  *
  *  This library is free software; you can redistribute it and/or
  *  modify it under the terms of the GNU Lesser General Public
  *  License as published by the Free Software Foundation; either
@@ skipping 49 matching lines @@
         exceptionState.throwDOMException(NotSupportedError, "No user media controller available; is this a detached window?");
         return;
     }
 
     String errorMessage;
     if (navigator.frame()->document()->isPrivilegedContext(errorMessage)) {
         UseCounter::count(navigator.frame(), UseCounter::GetUserMediaSecureOrigin);
     } 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);
     if (!request) {
         ASSERT(exceptionState.hadException());
         return;
     }
 
     request->start();
 }
 
 } // namespace blink