Created attachment 409877 [details] Patch

Created attachment 409880 [details] Patch

Comment on attachment 409880 [details] Patch I don’t think this is exactly what we want. If a process does not have the entitlements, you said earlier that trying to do the operation can lead to a crash. We don’t want a WKWebViewConfiguration value that can be set that leads to a crash. Configuration options should be choices/requests. The default can be true as long as the code responds by not advertising the capability to the web content, and not crashing, when entitlements are not available.

(In reply to Darin Adler from comment #3) > Comment on attachment 409880 [details] > Patch > > I don’t think this is exactly what we want. If a process does not have the > entitlements, you said earlier that trying to do the operation can lead to a > crash. We don’t want a WKWebViewConfiguration value that can be set that > leads to a crash. Eric mentioned we could crash but I am not exactly sure of the exact code path. The choice can be made independently of the entitlements. For instance, WebKitTestRunner and TestWebKitAPI are supporting loading pages that call getUserMedia: they do not have entitlements but use mock media devices for instance. If an app has camera entitlement but not microphone entitlement, I would believe getUserMedia would be supported but we would return OverConstrainedError in case the page wants to start capturing audio. We should not crash in any of these cases.

Discussing with Eric, we could indeed add both entitlement and Plist checks. It seems like a misconfiguration to add entitlements but not the Plist. Seems ok to add all checks, especially if PLIst checks can be done synchronously.

Created attachment 409964 [details] WIP patch

Created attachment 410005 [details] WIP patch

Created attachment 410017 [details] WIP patch

I am still not comfortable with the approach here. Automatically setting *preferences* to match entitlements does not seem like the correct design for this, or any other feature. Obviously entitlements should control *capabilities*, but I see no reason they would alter a preference setting. This is not about whether preferences should exist, but rather the design for how preferences work. They don’t automatically set themselves; the settings flow in from the app using WebKit, and are consulted along with other considerations to determine the behavior of WebKit. I do not think it’s helpful to set a preference based on entitlements. There’s a whole separate debate about whether a given preference should exist, but that’s not my point at all.

OK, let's first fix the potential crash issue for now and finalize the discussion about a preference.

Closing. We will prevent an incorrectly configured app from being terminated in bug 217104.

I think we should compute a default value for WKWebViewConfiguration._mediaCaptureEnabled according Info.plist, at least until we provider proper API.

(In reply to youenn fablet from comment #12) > I think we should compute a default value for > WKWebViewConfiguration._mediaCaptureEnabled according Info.plist, at least > until we provider proper API. Why? That makes no sense to me. Who does that help? How does it help them?

(In reply to Darin Adler from comment #13) > (In reply to youenn fablet from comment #12) > > I think we should compute a default value for > > WKWebViewConfiguration._mediaCaptureEnabled according Info.plist, at least > > until we provider proper API. > > Why? That makes no sense to me. It is always good to provide good default values, especially if we do not provide APIs to change it. If an application has no way to have a functional getUserMedia, it seems good to not expose getUserMedia at all. If an application can have a functional getUserMedia, it seems good to expose it. > Who does that help? How does it help them? Web developers can do feature detection more easily with a missing getUserMedia than with a getUserMedia that always reject.

(In reply to youenn fablet from comment #14) > It is always good to provide good default values, especially if we do not > provide APIs to change it. I don’t know if I agree or disagree with this. I don’t know what it means. > If an application has no way to have a functional getUserMedia, it seems > good to not expose getUserMedia at all. I agree. We don’t need to change WKWebViewConfiguration to make that true. We should not expose getUserMedia if the app doesn’t have sufficient entitlement. That should not be done by changing WKWebViewConfiguration, but by adding code to make that happen. > If an application can have a functional getUserMedia, it seems good to > expose it. I agree.

(In reply to Darin Adler from comment #15) > (In reply to youenn fablet from comment #14) > > If an application can have a functional getUserMedia, it seems good to > > expose it. > > I agree. Actually, I’m not 100% sure about this. Might be privacy or security reasons to not expose by default for all apps; need to confirm that it’s best to have it on by default for all WebKit clients.

Work continued in https://bugs.webkit.org/show_bug.cgi?id=217319.