Open Bug 798983 Opened 12 years ago Updated 2 years ago

Adding fake:true with parameter combinations that are not supported fails to fire a NOT_SUPPORTED_ERR

Categories

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

18 Branch
defect

Tracking

()

backlog parking-lot

People

(Reporter: jsmith, Unassigned)

References

Details

Caught during creating the automated test for bug 795367. Looks like if you add fake:true, and use a combination of parameters that we don't support when calling mozGetUserMedia, then we fail to report a NOT_SUPPORTED_ERR. Examples combinations include:

- {picture: true, video: true, fake: true}
- {picture: true, audio: true, fake: true]
- {video: true, audio: true, picture: true, fake: true}
Blocks: 795367
Whiteboard: [getUserMedia]
(In reply to Jason Smith [:jsmith] from comment #0)
> Caught during creating the automated test for bug 795367. Looks like if you
> add fake:true, and use a combination of parameters that we don't support
> when calling mozGetUserMedia, then we fail to report a NOT_SUPPORTED_ERR.
> Examples combinations include:

Isn't that what we want? Even if we add faked media devices we have to show the same behavior as if fake wouldn't have been added. So if video and picture doesn't work neither this combination with fake should work. Or do I misinterpret something?
(In reply to Henrik Skupin (:whimboo) from comment #1)
> (In reply to Jason Smith [:jsmith] from comment #0)
> > Caught during creating the automated test for bug 795367. Looks like if you
> > add fake:true, and use a combination of parameters that we don't support
> > when calling mozGetUserMedia, then we fail to report a NOT_SUPPORTED_ERR.
> > Examples combinations include:
> 
> Isn't that what we want? Even if we add faked media devices we have to show
> the same behavior as if fake wouldn't have been added. So if video and
> picture doesn't work neither this combination with fake should work. Or do I
> misinterpret something?

Well, we want NOT_SUPPORTED_ERR to be fired, because the combinations in comment 0 provided are not valid combinations of parameters for gUM.
Oh misread it. So what do we get currently?
(In reply to Henrik Skupin (:whimboo) from comment #3)
> Oh misread it. So what do we get currently?

Both of these get a success callback:

- {picture: true, video: true, fake: true}
- {picture: true, audio: true, fake: true]

This one gets NOT_IMPLEMENTED:

- {video: true, audio: true, picture: true, fake: true}
Whiteboard: [getUserMedia] → [getUserMedia] [blocking-gum+]
Flags: in-testsuite?
Whiteboard: [getUserMedia] [blocking-gum+] → [getUserMedia] [blocking-gum-]
fake:true is non-spec, for testing/etc use, so this is low priority
backlog: --- → parking-lot
Component: WebRTC → WebRTC: Audio/Video
QA Contact: jsmith
Whiteboard: [getUserMedia] [blocking-gum-]
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.