Closed Bug 845727 Opened 7 years ago Closed 4 years ago

[meta] Make Camera API e10s ready

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(e10s-)

RESOLVED FIXED
Tracking Status
e10s - ---

People

(Reporter: chiajung, Unassigned)

References

(Blocks 1 open bug)

Details

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.
Blocks: 825110
chiajung, were you planning on working on this?  If not, I can take it on.
(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.
Blocks: e10s-webrtc
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.
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.
(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.
(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.
(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.
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!
No longer blocks: 862026
dealt with long ago
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.