806420 - Cam access with getUserMedia blocked if it has already been opened and not closed properly

Status: RESOLVED WONTFIX

(Core :: WebRTC, defect, P2)

Description

[Guyllaume Doyer]

Attachment: testgum.html

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.40 Safari/537.11

Steps to reproduce:

1) Access the cam with getUsedMedia, load the stream into a <video>
2) Remove the video tag from the dom without "closing" (pause) it
3) Try to access the cam again

This works as expected in Chrome and Opera, but not in Firefox.


Actual results:

Got the 'HARDWARE_UNAVAILABLE' error


Expected results:

Firefox should have accessed the stream.

This may be the same concerns than for the multi-tab access bug filed here :
https://bugzilla.mozilla.org/show_bug.cgi?id=788017

Comment 1

[Jason Smith [:jsmith]]

Hmm...the way we currently release access to the camera requires the caller to call stop() on the stream returned from gUM. Why is Chrome & Opera doing something different?

Comment 2

[Jason Smith [:jsmith]]

Anant - What's the spec say here for how the camera should be released if the DOM element is removed that is playing the content from a real-time stream?

I thought stop() was the only way we allowed it, but Opera and Chrome might be doing something different...

Comment 3

[Guyllaume Doyer]

Interesting. Did know about the stop() method on the stream. None of the demos hanging around was using it.

Works in Chrome but does not seem to be implemented on Opera (just filed a bug).

However, I still believe that Firefox, like others, SHOULD be able to gain access to the cam if another access has already been opened and not closed properly (and even if another tab or another page has already opened one).

Comment 4

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

We can gain access to it if the stream has been destroyed (no remaining references).

The primary difference is that we enable the camera as soon as it's allocated. This means that (probably) when Chrome removes the <video> element, the stream has no sink and they turn off access.  While we will keep the camera on so long as the stream has any references (such as in a JS var).  Neither behavior is currently part of the spec, and we feel that it's important to both keep the camera 'hot' (some take seconds to turn on) and also that it's often a privacy issue - letter ina app sit on an active permission with the camera off allows a number of attacks on privacy and chances for user surprise.

So, this is working as designed.  Someone wanting to give up access to a camera should call stop() and/or make sure there are no active references anymore.

There may be a bug with a stream that has no references taking a while to be GC'd and deleted (and thus making the camera available to others).  Filing a bug to verify that's handled correctly.  Resolving this one as wontfix (barring WG changes).