Currently, WebRTC is not e10s ready. For what I know, 1. Webrtc creates sockets in the content process which is not allowed. 2. The permission checks of camera api and audio capture

The first task here is to have a conversation about what we think the right architecture is here. I'll be following up on this next week when I get back from IETF.

I think we should discuss how to do that, too. We have some discussion in Taiwan locally, but no conclusion now. The ideal implementation would be let chrome process take care of hardware (audio/video/codec) and socket. Then content side just instruct chrome process about what they want. However, that would be a huge architecture change I think. :S By the way, Bug 845727 is for camera part. But I think the Camera API is only available on B2G currently.

Is Bug 834093 a duplicate of this bug?

I spent a while talking to Jonas Sicking about this yesterday. We really don't want to move everything into the chrome process because that obviates the security benefits of process separation. However, some of it does need to be in there, likely including proxies for the camera and microphone. Jonas also suggested the ICE stack because that will allow the chrome process to enforce the ICE consent guarantees.

I agree, it is necessary to Manage how to allocate camera hw resource to app/web page. But I don't want to move camera hw handling code to chrome process. To provide product level performance/quality, camera hw needs to be near to content process as possible. Some problem is at Bug 844248 and Bug 848627. For Firefox OS 1.1, we should not do big change about how to handle camera stream. In Bug 803471, I moved camera hw hal and hw codec to android's media server process as a short term solution for FirefoxOS 1.1. It does not request a big change to how to handle camera and codec in gecko. And still can get good performance and normal content process can use camera/codec hw. Do this at camera hw is easier than hw codec. About hw codec, it become very difficult to do it. For a longer term, "Implement a dedicated 'media service' process" is a way to go, I think. Bug 845209, Bug 785592 are related bug. By implement the service process, we can replace "android's media server process". And we can do a correct permission check in the serviec process.

(In reply to Sotaro Ikeda [:sotaro] from comment #5) > > In Bug 803471, I moved camera hw hal and hw codec to android's media server > process as a short term solution for FirefoxOS 1.1. It does not request a > big change to how to handle camera and codec in gecko. And still can get > good performance and normal content process can use camera/codec hw. Do this > at camera hw is easier than hw codec. About hw codec, it become very > difficult to do it. > > For a longer term, "Implement a dedicated 'media service' process" is a way > to go, I think. Bug 845209, Bug 785592 are related bug. By implement the > service process, we can replace "android's media server process". And we can > do a correct permission check in the serviec process. I put "Do this at camera hw is easier than hw codec...." in a wrong position. Following is correct one. -------------------------------------- In Bug 803471, I moved camera hw hal and hw codec to android's media server process as a short term solution for FirefoxOS 1.1. It does not request a big change to how to handle camera and codec in gecko. And still can get good performance and normal content process can use camera/codec hw. For a longer term, "Implement a dedicated 'media service' process" is a way to go, I think. Bug 845209, Bug 785592 are related bug. By implement the service process, we can replace "android's media server process". And we can do a correct permission check in the serviec process.Do this at camera hw is easier than hw codec. About hw codec, it become very difficult to do it.

I recently did a review (bug 1036653) of new webrtc screen sharing code which generated a discussion about webrtc's current architecture which is not e10s/sandbox compatible. The issues are that device capture / interfacing and desktop/window screen sharing happen entirely in the child process. Giving access to these devices in the child has security consequences, and additionally when we turn on sandboxing, none of this code will work on Windows since sandboxed processes run in a locked down, low integrity, virtual desktop. The required work here apparently entails significant architectural changes. :/

I've asked GCP to track the changes needed for WebRTC under e10s and sandboxing.

Moving old M2 P1 bugs to M3.

This is a meta, which typically don't prioritize. We prioritize the dependent bugs (except at the very beginning - prior to bug breakdown).