Open Bug 811324 Opened 12 years ago Updated 2 years ago

Deal with non-unique "uniqueId"s in webrtc device lists

Categories

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

Product:
Core
Component:
WebRTC: Audio/Video
Type:
defect

Tracking

()

Blocking Flags:
backlog webrtc/webaudio+

People

(Reporter: jesup, Unassigned)

References

(Blocks 1 open bug)

Details

Since we don't get uniqueId's from Mac and Linux, and so use the deviceNames, but this means we could get non-unique id's used for the hash, and we fetch entries from the hash based on this (and so might get the wrong one). See bug 809554 Possible solution: use the internal structure address we're associating this with as the hash/uniqueId if one isn't provided. Note that the index is also used in some fashions, and as Tim mentions hotplugging might invalidate the indexes, so some more examination/thought is needed. P2, if we're sure we don't get dups of deviceNames, P3
Depends on: 861280
backlog: --- → webRTC+
Rank: 25
If we are happy with Randell's proposed solution, I could create a fix that set the uniqueId by the address of the recording device structure, when it is not provided.
Whiteboard: [getUserMedia], [blocking-gum-]
Mass change P2->P3 to align with new Mozilla triage process.
Priority: P2 → P3

FYI, still relevant?

Flags: needinfo?(jib)

I think this is still an issue given bug 1740727.

Flags: needinfo?(jib)
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.