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)
Tracking
()
NEW
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}
Reporter | ||
Updated•12 years ago
|
Whiteboard: [getUserMedia]
Comment 1•12 years ago
|
||
(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?
Reporter | ||
Comment 2•12 years ago
|
||
(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.
Comment 3•12 years ago
|
||
Oh misread it. So what do we get currently?
Reporter | ||
Comment 4•12 years ago
|
||
(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}
Updated•12 years ago
|
Whiteboard: [getUserMedia] → [getUserMedia] [blocking-gum+]
Reporter | ||
Updated•12 years ago
|
Flags: in-testsuite?
Reporter | ||
Updated•12 years ago
|
Whiteboard: [getUserMedia] [blocking-gum+] → [getUserMedia] [blocking-gum-]
Comment 5•9 years ago
|
||
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-]
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•