845727 - [meta] Make Camera API e10s ready

Status: RESOLVED FIXED

(Firefox OS Graveyard :: General, defect)

Description

[Chiajung Hung [:chiajung]]

Currently, we can not access Camera API from Browser app even we add camera permission into manifest. Since Camera API will check permission against a windowID in child process rather than that one we grant permission.

We want the Browser app prompt when Camera permission needed.

Comment 1

[Mike Habicher [:mikeh] (high bugzilla latency)]

chiajung, were you planning on working on this?  If not, I can take it on.

Comment 2

[Chiajung Hung [:chiajung]]

(In reply to Mike Habicher [:mikeh] from comment #1)
> chiajung, were you planning on working on this?  If not, I can take it on.

WOW, if you can help this part, please just take it!!
We need this to let WebRTC video module in Bug 825110 compatible with Browser App after architectural change to utilize dom/camera modules.

Comment 3

[Sotaro Ikeda [:sotaro]]

Hi Chia-Jung and Mike,

It seems that the meaning of e10s is not clear. From original meaining, e10s is multiple content process support.

From that point of view, bug 803471 fixed the problem of camera. Until the bug is landed, normal content process can not access camera hw. Camera app's process needed special privilege to access camera hw. It is decidecd when content process started. It could not be changed after that.

The privileges are assigned in the following.
http://mxr.mozilla.org/mozilla-central/source/ipc/chromium/src/base/process_util_linux.cc#305

Since bug 803471 landed, there is no such restriction except camera recording. Normal content process could access camera hw now.
Camera recording needs to create a recording file within content process, then AID_SDCARD_RW is still necessary only for VIDEO recording. Bug 849330 is going to remove other privileges except AID_SDCARD_RW.

Bug 845727 seems like related to general permission assignment mechanizm to a normmal web content. when web content is going to use camera capability. Trusted UI asked to a user to use camera on the content. If the user agreed to use the camera, camera hw is enabled on the content's domain. The user can manage the assinged permission from Setting app. There is alreay such mechanism for apps in FirefoxOS, but not for a web page. It needs to extend for it.

Comment 4

[[:fabrice] Fabrice Desré]

Being e10s ready is more about making sure that we do the right thing when multiple apps want to access the camera. I don't think we support that properly now.

Comment 5

[Sotaro Ikeda [:sotaro]]

(In reply to Fabrice Desré [:fabrice] from comment #4)
> Being e10s ready is more about making sure that we do the right thing when
> multiple apps want to access the camera. I don't think we support that
> properly now.

To do it, it is necessary to implement resource manager kind of thing in gecko. It is also necessary to hw codec usage control. I am going to fix about hw codec problem in Bug 831747.

Comment 6

[Mike Habicher [:mikeh] (high bugzilla latency)]

(In reply to Fabrice Desré [:fabrice] from comment #4)
>
> Being e10s ready is more about making sure that we do the right thing when
> multiple apps want to access the camera. I don't think we support that
> properly now.

With the changes in bug 803471, any attempt to open the camera beyond the first will fail on the busy hardware, and logcat will show an error to that effect.

This seems acceptable to me, unless we want to:
1. allow multiple app to be able to control the camera simultaneously; or
2. ensure that the MRU camera-using application always gets the camera.

Comment 7

[[:fabrice] Fabrice Desré]

(In reply to Mike Habicher [:mikeh] from comment #6)
> (In reply to Fabrice Desré [:fabrice] from comment #4)
> >
> > Being e10s ready is more about making sure that we do the right thing when
> > multiple apps want to access the camera. I don't think we support that
> > properly now.
> 
> With the changes in bug 803471, any attempt to open the camera beyond the
> first will fail on the busy hardware, and logcat will show an error to that
> effect.

And this is reported up to the DOM layer I guess?

> This seems acceptable to me, unless we want to:
> 1. allow multiple app to be able to control the camera simultaneously; or
> 2. ensure that the MRU camera-using application always gets the camera.

I think I want 2. What happens if:
1) I open the camera app
2) I go back to the homescreen
3) I open another app using the camera

I expect the second app to be able to use the camera.

Comment 8

[Chiajung Hung [:chiajung]]

The scenario for me is to open camera from BrowserApp which grant camera permission to BrowserApp do not work. 
(In reply to Sotaro Ikeda [:sotaro] from comment #3)
> Bug 845727 seems like related to general permission assignment mechanizm to
> a normmal web content. when web content is going to use camera capability.
> Trusted UI asked to a user to use camera on the content. If the user agreed
> to use the camera, camera hw is enabled on the content's domain. The user
> can manage the assinged permission from Setting app. There is alreay such
> mechanism for apps in FirefoxOS, but not for a web page. It needs to extend
> for it.

In fact, this what we want!

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

dealt with long ago