797796 - getUserMedia backend needs to pass all necessary data to the UI

Status: RESOLVED FIXED

(Core :: WebRTC, defect)

Description

[Dão Gottwald [:dao]]

data needed:
- DOM window
- nsIMediaStreamOptions
- id or handle for the UI to approve or deny the request

Comment 1

[Anant Narayanan [:anant]]

Attachment: Hookup gUM backend with the UI

The only change from the patch in bug 729522 is that we now pass a JSON structure with the windowID and callID instead of just the callID.

Comment 2

[Anant Narayanan [:anant]]

Attachment: Hookup gUM backend with the UI

Forgot to qref :/

Comment 3

[Anant Narayanan [:anant]]

Attachment: Hookup gUM backend with the UI

Pass outer window ID instead of inner window ID.

Comment 4

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

Comment on attachment 668183 [details] [diff] [review]
Hookup gUM backend with the UI

Review of attachment 668183 [details] [diff] [review]:
-----------------------------------------------------------------

r=jesup with the snprintf(windowBuffer,sizeof(windowBuffer),...)

::: dom/media/MediaManager.cpp
@@ +390,5 @@
> +  Denied()
> +  {
> +    if (NS_IsMainThread()) {
> +      nsCOMPtr<nsIDOMGetUserMediaErrorCallback> error(mError);
> +      error->OnError(NS_LITERAL_STRING("PERMISSION_DENIED")); 

trailing space

@@ +725,5 @@
> +    data.Append(NS_LITERAL_STRING("{\"windowID\":"));
> +
> +    // Convert window ID to string.
> +    char windowBuffer[32];
> +    sprintf(windowBuffer, "%ld", aWindow->GetOuterWindow()->WindowID());

paranoia: snprintf please.  Yes, I know MAX_UINT64_T is less than 32 characters

@@ +822,5 @@
> +    // Close off any remaining active windows.
> +    mActiveWindows.Clear();
> +    mActiveCallbacks.Clear();
> +    sSingleton = nullptr;
> +    

trialing spaces a couple of places here.  Search the file for them.  Emacs has a function (of course)

Comment 5

[Dão Gottwald [:dao]]

What happens with regards to audio if both video and audio are requested and the front-end sends getUserMedia:response:allow for a particular video device?

Comment 6

[Anant Narayanan [:anant]]

The default audio device will be selected. I guess we'll need a way to signal a specific audio device as well. Right now, getUserMedia can only return a stream from a single device, but this is an issue when we fix that bug.

Since we have to pass an object across the event using the subject parameter, the only way I can think of doing this is with two getUserMedia:response:allow messages, with the first one signaling somehow that there is another event on the way.

Comment 7

[Anant Narayanan [:anant]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6f4ab9a3d734

Comment 8

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/6f4ab9a3d734