[Browser] Add WebView.mediaAccessPermissionRequested API

[Chris Coulson]

This keeps getting pushed aside by other tasks, but it's really about time we got this done (as it's required for sites to be able to access the camera / microphone)

--- --- --- ---

UX Comment:
Relevant wireframes/pages added to specification:
https://docs.google.com/presentation/d/1Qrd4Flfs3EH-fI79IfrYgLdAx2nce-L7ve8NKLCX324/edit#slide=id.g3ddd7bb9c_00

[Olivier Tilloy (osomon)]

Just added a webbrowser-app task to track the use of the new oxide API in the browser.

Test page for microphone permission requests: https://voice-memos.appspot.com/.

[yusuf75 (yusuf-uzunyilmaz-googlemail)]

... fix released ? I try it but it dont works

[Andrea Bernabei (faenil)]

can any developer provide more info about what's needed for this to actually be implemented in the browser?

[Olivier Tilloy (osomon)]

Time and prioritization.

[Olivier Tilloy (osomon)]

Added an ubuntu-ux task as we also need some design guidance for the UI/UX part.

[Olivier Tilloy (osomon)]

I just did a quick test by modifying the webview implementation in the browser to always accept media access permission requests:

    WebView {
        onMediaAccessPermissionRequested: request.allow()
    }

And this is enough to make audio recording just work (successfully tested with https://voice-memos.appspot.com/).
Video doesn’t seem to work though, it will probably require more work.

The first time the browser requests access to the microphone, I get a trust prompt saying: "Chrome input wants to record audio.".
This decision is remembered, but when I go to system-settings>security>access>mic, there is an empty entry for the browser (chrome input). The contents of /home/phablet/.local/share/PulseAudio/trust.db is as follows:

    sqlite> select * from requests;
    Id|ApplicationId|Feature|Timestamp|Answer
    1|Chrome input|0|1439981817195438084|1

This is not very user friendly, I guess system settings try to match the application ID ("Chrome input") with an existing confined app, and failing to do that it displays an empty entry. I wonder if we could add an API to oxide to allow the embedder to override the application ID that is passed to the query.

[Olivier Tilloy (osomon)]

We need a UX specification for the media permission request handling.

Whenever a website requests access to the camera and/or the microphone, oxide emits a signal with the following information:
 - isForAudio (boolean)
 - isForVideo (boolean)
 - origin (URL)
 - embedder (URL)

At this point the browser can either allow or deny access, and the decision will be automatically remembered for the duration of the session (as soon as the browser app is closed and re-opened, the permissions will be requested again).

We can build in a persistent mechanism for remembering user decisions if they want to, but it should probably be opt-in, i.e. the user would choose between:
 - denying access for this session
 - permanently denying access
 - allowing access for this session
 - permanently allowing access

Additionally, we would need a UI (probably under settings) to allow the user to forget/modify persistent decisions. If a user chose to permanently authorize a given domain, they should be able to:
 - uncheck a checkbox to permanently deny access for that domain
 - delete the entry to ensure that next time that domain requests access the user will be prompted again

Oxide also gives us access to the list of audio/video capture devices and allows setting the default device for audio and video. We might want to have an extra piece of UI to allow the user to select the default device for each media type, although that’s probably less urgent since typically on a phone there will only be one device for each media type, so nothing to choose from.

[Chris Coulson (chrisccoulson)]

Olivier, can you report a separate bug for the application ID issue? We probably don't want a separate API for that, but we could probably just use QCoreApplication::applicationName

[Olivier Tilloy (osomon)]

Done: bug #1486645.

[Launchpad Janitor (janitor)]

This bug was fixed in the package webbrowser-app - 0.23+15.10.20151022.1-0ubuntu1

---------------
webbrowser-app (0.23+15.10.20151022.1-0ubuntu1) wily; urgency=medium

  [ CI Train Bot ]
  * New rebuild forced.
  * Resync trunk.

  [ Olivier Tilloy ]
  * Add an exception to the generated apparmor profile to allow reading
    HERE’s TOS in the browser. (LP: #1507667)
  * Modify the generated apparmor profile to allow rw access to
    /dev/shm/.org.chromium.Chromium.* too. (LP: #1508054)
  * Update translation template.

  [ Ugo Riboni ]
  * Fix inability to drag the map to pan in Google maps, on desktop.
    (LP: #1503506)
  * Implement support for allowing or denying access to media input
    devices and for setting default media input devices. (LP: #1410996)
  * Refactor the BookmarksModel to be a singleton.

 -- Olivier Tilloy <email address hidden> Thu, 22 Oct 2015 15:07:49 +0000

[Marco A. Harrendorf (marcokarlo)]

Dear all,

thank you very much for working on this and submitting a fix. Keep on pushing!

Partly WebRTC is now working. E.g. I can use appear.in to start a voice chat.

*However*, the camera is still not working with WebRTC and unless this I would consider WebRTC as not fully supported since websites like appr.tc still do not work due to the missing camera permission.

You can also test this using the official site https://test.webrtc.org/ and you will find that the camera access is not supported yet on BQ4.5

Please fix also this. Thanks

[Olivier Tilloy (osomon)]

@Marco: camera support is tracked by bug #1441465.