[Browser] Add WebView.mediaAccessPermissionRequested API

Bug #1410996 reported by Chris Coulson on 2015-01-14
142
This bug affects 26 people
Affects Status Importance Assigned to Milestone
Canonical System Image
High
Bill Filler
Oxide
High
Chris Coulson
Ubuntu UX
High
James Mulholland
webbrowser-app (Ubuntu)
High
Ugo Riboni

Bug Description

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

Related branches

Changed in oxide:
importance: Undecided → Critical
status: New → Triaged
milestone: none → branch-1.6
Changed in oxide:
assignee: nobody → Chris Coulson (chrisccoulson)
Changed in oxide:
milestone: branch-1.6 → branch-1.7
importance: Critical → High
Changed in oxide:
status: Triaged → In Progress
Changed in oxide:
milestone: branch-1.7 → branch-1.8
Changed in oxide:
status: In Progress → Fix Released
Olivier Tilloy (osomon) wrote :

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/.

Changed in webbrowser-app:
assignee: nobody → Olivier Tilloy (osomon)
importance: Undecided → High
status: New → Confirmed
Olivier Tilloy (osomon) on 2015-06-08
Changed in webbrowser-app (Ubuntu):
status: New → Confirmed
assignee: nobody → Olivier Tilloy (osomon)
importance: Undecided → High
no longer affects: webbrowser-app
Chaz (laccato-ve) on 2015-07-10
Changed in webbrowser-app (Ubuntu):
status: Confirmed → Fix Released
Olivier Tilloy (osomon) on 2015-07-27
Changed in webbrowser-app (Ubuntu):
status: Fix Released → Confirmed

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

Olivier Tilloy (osomon) on 2015-08-18
tags: added: webrtc
Andrea Bernabei (faenil) wrote :

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

Olivier Tilloy (osomon) wrote :

Time and prioritization.

Olivier Tilloy (osomon) wrote :

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

Olivier Tilloy (osomon) wrote :

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) wrote :

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.

Changed in ubuntu-ux:
status: New → Triaged
importance: Undecided → High
assignee: nobody → James Mulholland (jamesjosephmulholland)
Chris Coulson (chrisccoulson) wrote :

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) wrote :
summary: - Add WebView.mediaAccessPermissionRequested API
+ [Broswer] Add WebView.mediaAccessPermissionRequested API
summary: - [Broswer] Add WebView.mediaAccessPermissionRequested API
+ [Browser] Add WebView.mediaAccessPermissionRequested API
description: updated
Changed in ubuntu-ux:
status: Triaged → Fix Committed
Bill Filler (bfiller) on 2015-09-04
Changed in canonical-devices-system-image:
milestone: none → ww40-2015
assignee: nobody → Bill Filler (bfiller)
importance: Undecided → High
status: New → Confirmed
Ugo Riboni (uriboni) on 2015-09-14
Changed in webbrowser-app (Ubuntu):
assignee: Olivier Tilloy (osomon) → Ugo Riboni (uriboni)
status: Confirmed → In Progress
Changed in canonical-devices-system-image:
status: Confirmed → In Progress
Changed in canonical-devices-system-image:
milestone: ww40-2015 → ww46-2015
Launchpad Janitor (janitor) wrote :

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

Changed in webbrowser-app (Ubuntu):
status: In Progress → Fix Released
Bill Filler (bfiller) on 2015-10-30
Changed in canonical-devices-system-image:
status: In Progress → Fix Committed
Changed in ubuntu-ux:
status: Fix Committed → Fix Released
Changed in canonical-devices-system-image:
status: Fix Committed → Fix Released

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) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers