788017 - gUM video in multiple tabs not working - works correctly in Chrome

Status: RESOLVED INVALID

(Core :: WebRTC: Audio/Video, defect)

Description

[Andy Bajka]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:18.0) Gecko/18.0 Firefox/18.0
Build ID: 20120903030551

Steps to reproduce:

Tried to open more than one tab with this link:

http://alexandre.alapetite.fr/doc-alex/html5-webcam/


Actual results:

Only one tab shows the video


Expected results:

All tabs with this link open should show the video

Comment 1

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

Cameras are exclusive-access devices.  I believe this is expected behavior, but it can be compared to Chrome as a double-check.

Comment 2

[Andy Bajka]

If you try that link using Chrome you will see that the video displays in multiple tabs.

Comment 3

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

Hmmm.  Quite honestly, it probably shouldn't: which application is controlling the camera resolution?  (Also minor privacy leak in this case, but quite minor I think).  I suspect at most it will be left to the implementer what locking/ownership is implemented.  And this all falls into the purview of the Media Capture Task Force, and a spec still being written.

If you have any good arguments about why this *should* be the correct behavior, please make them.

Comment 4

[Andy Bajka]

Allowing multiple tabs to stream the video is a better option because if you navigate to a page which uses the camera, you expect it to work.

As for which script controls the camera resolution, that would be the current or active tab.

Comment 5

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

Circling in some of the other people involved in WebRTC and Media Capture.

Sounds like Chrome is obtaining the stream in a non-exclusive manner.  What does the current Constraints spec (not implemented by Chrome yet) say?

Comment 6

[Alexandre Alapetite]

For information, this bug also affects Firefox on Windows, as opposed to Chrome and Opera:

* Multiple tabs do not work either with Firefox Nighlty 18.0a1 from today on Windows 7.
* The example works fine with multiple tabs with Opera 12.01 on Windows 7.
* The example works fine with multiple tabs with Chrome 23.0.1255.0 dev-m on Windows 7.

Comment 7

[Guyllaume Doyer]

I agree with Andy. 

The cam stream SHOULD be accessible to all opened tabs, even when already opened in another.

Currently, we can access cam stream even if it's already opened in another browser. Why whouldn't this allowed on multiple tabs inside the same browser. 
This is not logic.

Chrome and Opera work as expected (tested on a Macbook Pro).

This may be the same concerns than for this bug I just filed :
See also https://bugzilla.mozilla.org/show_bug.cgi?id=806420

Comment 8

[Eric Rescorla (:ekr)]

Section 5.5 of the gUM spec (http://dev.w3.org/2011/webrtc/editor/getusermedia.html) recommends (but does not require) exclusive access to devices: 

"The user agent is encouraged to reserve resources when it has determined that a given call to getUserMedia() will succeed. It is preferable to reserve the resource prior to invoking the success callback provided by the web page. Subsequent calls to getUserMedia() (in this page or any other) should treat the resource that was previously allocated, as well as resources held by other applications, as busy. Resources marked as busy should not be provided as sources to the current web page, unless specified by the user. Optionally, the user agent may choose to provide a stream sourced from a busy source but only to a page whose origin matches the owner of the original stream that is keeping the source busy."

IOW, I believe  Firefox is spec conformant here. The right place to argue this is in the W3C media capture task force.

Comment 9

[Jason Smith [:jsmith]]

Eric - Should we close this as not valid then, since we are spec conformant?

Comment 10

[Eric Rescorla (:ekr)]

Not sure how things usually work with bugzilla. This is a topic of a lot of discussion, so the spec may change. i don't mind holding this open as a placeholder, but I'm not enthusiastic about changing it while the standards issue is still open.

Comment 11

[Jason Smith [:jsmith]]

(In reply to Eric Rescorla from comment #10)
> Not sure how things usually work with bugzilla. This is a topic of a lot of
> discussion, so the spec may change. i don't mind holding this open as a
> placeholder, but I'm not enthusiastic about changing it while the standards
> issue is still open.

Okay. Hmm...I think what we can do is close this as out for now as not valid, as we don't have plans to implement this in the short-term. If we end up needing to implement this in the future, then we can reopen this bug.