Steps to reproduce: 1. Load data:text/html,<iframe src="https://people.mozilla.org/~fqueze2/webrtc/"></iframe><iframe src="https://people.mozilla.org/~fqueze2/webrtc/"></iframe> 2. In the first iframe, click the "Audio" button and share your microphone. 3. In the second iframe, click the "Video" button and share your camera. Expected result: there should be a camera icon in the url bar and clicking it should show a doorhanger saying "You are currently sharing your camera and microphone with this page." Actual result: there's a microphone in the urlbar, and clicking it shows a message that doesn't mention that the camera is being shared. Note: the global sharing indicator isn't affected by this bug. This is clearly a regression from https://hg.mozilla.org/mozilla-central/rev/846759ed5d7c / bug 973001.

Do we actually need to support gUM requests in subframes? Can we just disable that completely?

gUM requests in subframes are certainly making our lives harder, but I don't think that's a convincing argument to stop supporting them, especially as some existing websites may already use them.

"May" isn't good enough :) I'm less concerned about implementation difficulty, I'm more concerned about the fundamental issues with a permissions UI that has to handle them (cross-origin subframes in particular).

I think you want to ask jesup for a more solid answer.

I don't know if production sites are using them directly for webrtc (certainly possible; I don't know of any but there are a lot of sites out there and a bunch of custom uses in places like call centers); they were considered as part of the overall security design authored by ekr in the IETF/W3 for WebRTC. I have seen this in the wild (which exposed a problem with "stop sharing") when you use getUserMedia on jsfiddle, which is something people will certainly do when trying stuff. ekr, mt: comments?

I think that :gavin is right on the money. If we have multiple origins requesting access, the one that the request is attributed to from the user's perspective is the one that appears in the bar at the top. Just because example.com frames in evil.com, it doesn't mean that it endorses it's requests for access to media. I have no issue enabling same-origin requests from frames - in fact, that's a good idea - but cross-origin grants are a problem. Same origin grants may still expose this particular bug, but that's orthogonal. :jib can probably help on the bug.

This restores the behavior we had before bug 973001.

I think I agree with Martin and Gavin that cross-origin requests are problematic and should be disallowed since it strongly implies endorsement. But surely there's a precedent and this isn't the first time implied endorsement has come up as an issue with iframes? e.g. what does geolocation do? Agree with Florian that the old behavior is better for dealing with multiple same-orgin requests (oddly it seems to work for multiple requests from the *same* page). I still see some related problems here though: for instance, if I don't accept the audio request before making the video request, then the UI gets confused and looses one request, but that seems like a separate bug.

https://hg.mozilla.org/integration/fx-team/rev/6fa1218092a2 (In reply to Jan-Ivar Bruaroey [:jib] from comment #8) > I still see some related problems here though: for instance, > if I don't accept the audio request before making the video request, then > the UI gets confused and looses one request, but that seems like a separate > bug. I also noticed this, but it's not a regression from bug 973001; I verified that this problem also exists on aurora. So yes, separate bug. I'm hoping implementing the new design from bug 1058775 is the good long term solution for these edge cases. Note that not allowing cross origin gUM would let us simplify this design (the case in the image 5 of attachment 8485640 [details] would no longer exist).

Reproduced with Nightly 2014-09-23 on Windows 7 64-bit with STR from comment 0. Verified as fixed with latest Aurora 35.0a2 (Build ID: 20141124004001) and Nightly 36.0a1 (Build ID: 20141123030204) on Windows 7 64-bit, Mac OS X 10.9.5 and Ubuntu 12.04 32-bit. While doing some additional exploratory testing on this issue, found bug 1104054 (also reproducible with builds before this fix: 2014-09-29).