Closed Bug 835892 Opened 11 years ago Closed 11 years ago

Provide No Video & No Audio options when both camera and microphone access are requested

Categories

(Firefox :: Site Permissions, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 21
Tracking Status
firefox20 --- wontfix
firefox21 --- fixed

People

(Reporter: dao, Assigned: dao)

Details

(Whiteboard: [getUserMedia])

Attachments

(1 file)

Attached patch patchSplinter Review
      No description provided.
Attachment #707699 - Flags: review?(gavin.sharp)
Attachment #707699 - Flags: feedback?(rjesup)
Comment on attachment 707699 [details] [diff] [review]
patch

It's kind of weird that selecting both "No Video" and "No Camera" and hitting "Share Selected Devices" is the same as hitting "Don't Share" - I guess ideally you would prevent that from being a choice, but I guess that may not be worth worrying about.
Attachment #707699 - Flags: review?(gavin.sharp) → review+
https://hg.mozilla.org/mozilla-central/rev/b8dcf873cfa1
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 21
Attachment #707699 - Flags: feedback?(rjesup)
The behavior that is introduced by this bug violates the current MediaStream specification [1] [2], which states the following:

When the getUserMedia() method is called, the user agent must run the following steps:
1. Let constraints be the method's first argument. (...)
6. Let finalSet be an (initially) empty set. (...)
8. For each media type T in requestedMediaTypes,
  1. Let candidateSet be all possible tracks of media type T that the browser could return.
  2. If the value of the T entry of constraints is "true", jump to the step labeled final below. Otherwise, continue. (...)
  6. Final: Add the tracks in the candidateSet to the finalSet. (...)
11. The provided media must include precisely one track of each media type in requestedMediaTypes from the finalSet.

Chrome also behaves in a non-compliant way: https://crbug.com/416162. Since both implementations allow omission of the media stream, either the spec needs to be changed, or the "No video" / "No audio" options should be removed.

What's your take on it?


[1] http://www.w3.org/TR/2013/WD-mediacapture-streams-20130903/#dom-navigator-getusermedia
[2] http://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevices-getusermedia
Better to file a new bug and reference/block this one...  this could easily have been lost/ignored on an old, long-closed bug with few cc members.

The spec also indicates users should have control over what they share.  The spec as written doesn't handle the case of "user wants to share audio but not video", which No Video provides.

File a bug on the spec.  Per discussions, this is what is wanted anyways and generally agreed to.  An alternative to what the browsers do would be to provide silence/black (or a no-camera slate) if the user declines that track, though I would argue against doing that in favor of what browsers currently do.
We should probably ask the working group to permit this.  I see no reason why a request of this nature would be rejected.
Component: General → Device Permissions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: