WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
210104
getUserMedia don't remember permissions when asked from inside iframe
https://bugs.webkit.org/show_bug.cgi?id=210104
Summary
getUserMedia don't remember permissions when asked from inside iframe
Adam Szmyd
Reported
2020-04-07 04:45:12 PDT
It looks like for some weird reason Safari on iOS 12 is not remembering granted permissions when it's invoked from inside iframe (even on the same domain, not cross domain). Steps (for video but its the same for audio): 1. Put an iframe with code to get user media and add it `allow="camera"` attribute 2. Run `navigator.mediaDevices.getUserMedia({video: true})` from inside an iFrame 3. You'll see system permission prompt for granting access to camera - that's ok as it's the first time you ask for permission. Grant access 4. Run `getUserMedia` again 5. You'll see another system prompt even tough you just granted the permission (and captured stream is even still in memory. Removing it before next attempts do not change anything so im not describing that part) It behaves differently when you're asking from outside iframe (being on page that hosts the iframe): 1. Run `getUserMedia` 2. You'll see system permission prompt. Grant permission 3. Run `getUserMedia` again 4. There is no additional prompt, media stream is just captured for you. Even if you "clear" the earlier captured stream (by invoking `getTracks().forEach(track => track.stop())`) it's still working as expected and remember the state of permission you just granted. There is a workaround that seems to work: 1. Run `getUserMedia` from host page (outside of iframe). Grant permission 2. Run `getUserMedia` from inside iframe 3. You'll only see one system permission prompt (the host page one) and every next attempts simply works. There is one additional issue with above workaround: `enumerateDevies`. It looks like that if you ask for permission from outside iframe and then from inside, enumerateDevices call called from inside of iframe acts like if it wouldn't have permission (device labels are empty). So the final workaround (with having enumerateDevices working) is to either ask for permission twice (first from inside iframe, then from outside) or ask once (outside iframe) and send list of devices from outside to inside (i.e. via postMessage for cross domain cases). Both workarounds are quite ugly. I created simple page to reproduce the problem:
https://aszmyd.github.io/sandbox/safari-permission-bug
- Simply do the steps i descibed above on that page and you'll see what the issue is about. I saw this problem on: * Safari 12 on iOS 12.4.3 * Safari 12 on iOS 12.4.5 * Safari 12 on iOS 12.4.6
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2020-04-07 11:49:51 PDT
<
rdar://problem/61403196
>
youenn fablet
Comment 2
2020-05-12 04:56:23 PDT
As per spec, enumerateDevices is now no longer exposing devices if the context is not capturing or did not capture in the past. As of the prompt policy, we also scope it by context. I am not exactly sure whether you report a bug in the implementation of the policy or in the policy itself. From your example, it seems the policy behaves as expected in STP: two prompts will happen for outside and inside frames, no matter the order of the calls. I guess we could allow to reuse a policy for all same-origin iframes. Would that help you? For third-party iframes, I think we will want to continue prompting.
Adam Szmyd
Comment 3
2020-05-12 16:09:23 PDT
But the issue is about not remembering permission (reusing policy as you wrote) for multiple getUserMedia asks from inside iframe. It's inconsistent with the same scenario outside of iFrame and it behaves differently (correctly IMO) in iOS 13 version. It just feels that if the user granted permission for a frame and captured stream was NOT destroyed, next getUserMedia asks should just work the same as it is outside iframe or in iOS 13.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug