Summary: | Implement <iframe allow="camera; microphone"> | ||
---|---|---|---|
Product: | WebKit | Reporter: | Simon Pieters (:zcorpan) <zcorpan> |
Component: | DOM | Assignee: | youenn fablet <youennf> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | andersca, buildbot, cdumez, commit-queue, dccollie, eric.carlson, ews-watchlist, jonlee, marc, mike.stark, rniwa, szmydadam, webkit-bug-importer, youennf |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari Technology Preview | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=183300 | ||
Attachments: |
Description
Simon Pieters (:zcorpan)
2017-01-25 13:47:58 PST
The recent release of Safari 11 adds support for WebRTC. This opens up an opportunity to finally replace Flash based camera recording. However, the following checks prevent calling getUserMedia from an iframe. https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/mediastream/UserMediaRequest.cpp#L116 https://github.com/WebKit/webkit/blob/master/Source/WebCore/page/SecurityOrigin.cpp#L563 If 'allowusermedia' was implemented it would allow different webrtc camera recording implementations that are iframed into client sites to function. Currently, they have to fallback to flash. (In reply to Dave Collie from comment #1) > The recent release of Safari 11 adds support for WebRTC. This opens up an > opportunity to finally replace Flash based camera recording. However, the > following checks prevent calling getUserMedia from an iframe. > > https://github.com/WebKit/webkit/blob/master/Source/WebCore/Modules/ > mediastream/UserMediaRequest.cpp#L116 > > https://github.com/WebKit/webkit/blob/master/Source/WebCore/page/ > SecurityOrigin.cpp#L563 > > If 'allowusermedia' was implemented it would allow different webrtc camera > recording implementations that are iframed into client sites to function. > Currently, they have to fallback to flash. What different implementations are out there that have wide deployment? Cameratag (https://cameratag.com/demo) currently doesn't work with Safari 11 unless flash fallback is forced. It doesn't require iframing but there are use cases where it's easier to implement cameratag on a subdomain and embed in other services. The company I work for is using the same strategy for our own recording platform and partner ecosystem. We were hoping with Safari 11 that we could finally relegate flash camera recording to IE11 only. For Chrome we use the 'allow' attribute https://wicg.github.io/feature-policy/#iframe-allow-attribute to permit accessing the camera and microphone. This doesn't appear to be implemented in Firefox. A mechanism to allow iframes to access camera/mic on behalf of the top document makes sense to me. That said, allowusermedia might be removed from the spec and replaced by something like https://wicg.github.io/feature-policy/ Created attachment 323176 [details]
Patch
Comment on attachment 323176 [details] Patch Attachment 323176 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/4800731 New failing tests: imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-MediaElement-srcObject.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-audio-only.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-id-manual.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-idl.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStreamTrack-MediaElement-disabled-audio-is-silence.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStreamTrack-getSettings.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-default-feature-policy.https.sub.html imported/w3c/web-platform-tests/mediacapture-streams/GUM-trivial-constraint.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaDevices-IDL-enumerateDevices.html imported/w3c/web-platform-tests/mediacapture-streams/GUM-deny.https.html imported/w3c/web-platform-tests/mediacapture-streams/GUM-impossible-constraint.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-video-only.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-MediaElement-preload-none.https.html imported/w3c/web-platform-tests/mediacapture-streams/GUM-optional-constraint.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-finished-add.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-removetrack.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-add-audio-track.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStreamTrack-init.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStreamTrack-id.https.html imported/w3c/web-platform-tests/mediacapture-streams/MediaStream-gettrackid.https.html Created attachment 323179 [details]
Archive of layout-test-results from ews102 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews102 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 323185 [details]
Patch
Comment on attachment 323185 [details]
Patch
We need to discuss this change in policy. Third-party frames are disallowed for a reason.
Is there any progress on this one? We're implementing a voice client that uses iFrames to allow users to plug our embedded iFrame on their side and allow communication. Current Safari11 gives us this error "Trying to call getUserMedia from a document with a different security origin than its top-level frame." Can someone give me an answer if capturing microphone from cross-domain iFrame (both host and child iFrame on HTTPS of course) will be possible? (In reply to Adam Szmyd from comment #11) > Is there any progress on this one? We're implementing a voice client that > uses iFrames to allow users to plug our embedded iFrame on their side and > allow communication. > > Current Safari11 gives us this error "Trying to call getUserMedia from a > document with a different security origin than its top-level frame." > > Can someone give me an answer if capturing microphone from cross-domain > iFrame (both host and child iFrame on HTTPS of course) will be possible? It was discussed at W3C TPAC and getUserMedia spec should be updated to support feature policy. That should help adoption here. (In reply to youenn fablet from comment #12) > > It was discussed at W3C TPAC and getUserMedia spec should be updated to > support feature policy. That should help adoption here. https://github.com/w3c/mediacapture-main/pull/440 Comment on attachment 323185 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=323185&action=review > Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:132 > + for (auto allowItem : StringView { allow }.split(';')) { > + auto item = allowItem.stripLeadingAndTrailingMatchedCharacters(isHTMLSpace<UChar>); > + if (requiresAudio && item == "microphone") > + requiresAudio = false; > + if (requiresVideo && item == "camera") > + requiresVideo = false; > + } > + return !requiresVideo && !requiresAudio; Nit: I think using local variable names like "allowCameraAccess" and "allowMicrophoneAccess" and revising this logic would make it easier to follow. Created attachment 329418 [details]
Patch for landing
Created attachment 329419 [details]
Patch for landing
Comment on attachment 329419 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=329419&action=review > Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:107 > +static bool isAllowedToUse(Document& document, Document& topDocument, bool requiresAudio, bool requiresVideo) Don't we normally eschew bool parameters and go for enums instead? > Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:153 > + return false; Is there an appropriate errorMessage we can return here? > Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:161 > errorMessage = "Trying to call getUserMedia from a document with a different security origin than its top-level frame."; This doesn't seem like the right message now. It should be something along the lines of "The top-level frame has prevented a document with a different security origin to call getUserMedia." Comment on attachment 329419 [details] Patch for landing View in context: https://bugs.webkit.org/attachment.cgi?id=329419&action=review >> Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:107 >> +static bool isAllowedToUse(Document& document, Document& topDocument, bool requiresAudio, bool requiresVideo) > > Don't we normally eschew bool parameters and go for enums instead? We usually do that for class methods or helper functions defined in headers. Since this is a static inline here and given the fact that we would need to compute the enum value at the call site, it does not seem very attractive. >> Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:153 >> + return false; > > Is there an appropriate errorMessage we can return here? I'll dig into it, I was thinking this could be some disconnected frame cases but I should check further. >> Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:161 >> errorMessage = "Trying to call getUserMedia from a document with a different security origin than its top-level frame."; > > This doesn't seem like the right message now. It should be something along the lines of "The top-level frame has prevented a document with a different security origin to call getUserMedia." ok, will update the message. Comment on attachment 329419 [details] Patch for landing Attachment 329419 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/5666709 New failing tests: imported/w3c/web-platform-tests/XMLHttpRequest/xmlhttprequest-sync-default-feature-policy.sub.html Created attachment 329429 [details]
Archive of layout-test-results from ews100 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Created attachment 329430 [details]
Patch for landing with fixed message
Created attachment 329431 [details]
Patch for landing with fixed message
(In reply to youenn fablet from comment #22) > Created attachment 329431 [details] > Patch for landing with fixed message Skipped xhr test which is timing out. Time out is triggered by the fact that the test is now going further due to added support for allow attribute. > > Source/WebCore/Modules/mediastream/UserMediaRequest.cpp:153
> > + return false;
>
> Is there an appropriate errorMessage we can return here?
I removed this additional check.
This is already in the code base and I saw another place which follows the same pattern without checking document.
There may be a bug though since for a disconnected frame, we might have a document but no parent document. Maybe we should check early for a frame.
This should be fixed in a follow-up anyway.
Comment on attachment 329431 [details] Patch for landing with fixed message Attachment 329431 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/5667449 New failing tests: http/tests/ssl/media-stream/get-user-media-nested.html http/tests/ssl/media-stream/get-user-media-different-host.html Created attachment 329438 [details]
Archive of layout-test-results from ews122 for ios-simulator-wk2
The attached test failures were seen while running run-webkit-tests on the ios-sim-ews.
Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.12.6
Comment on attachment 329431 [details] Patch for landing with fixed message Attachment 329431 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/5667507 New failing tests: http/tests/ssl/media-stream/get-user-media-nested.html http/tests/ssl/media-stream/get-user-media-different-host.html Created attachment 329440 [details]
Archive of layout-test-results from ews104 for mac-elcapitan-wk2
The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104 Port: mac-elcapitan-wk2 Platform: Mac OS X 10.11.6
Created attachment 329444 [details]
Patch
Comment on attachment 329444 [details] Patch Attachment 329444 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/5669030 New failing tests: webgl/1.0.2/conformance/context/context-release-upon-reload.html Created attachment 329454 [details]
Archive of layout-test-results from ews114 for mac-elcapitan
The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews114 Port: mac-elcapitan Platform: Mac OS X 10.11.6
Comment on attachment 329444 [details] Patch Clearing flags on attachment: 329444 Committed r225963: <https://trac.webkit.org/changeset/225963> All reviewed patches have been landed. Closing bug. |