Closed
Bug 828839
Opened 11 years ago
Closed 11 years ago
mozGetUserMedia should not be exposed if preffed off
Categories
(Core :: WebRTC, defect, P2)
Core
WebRTC
Tracking
()
RESOLVED
WONTFIX
Tracking | Status | |
---|---|---|
firefox18 | --- | wontfix |
firefox19 | - | wontfix |
firefox20 | --- | unaffected |
firefox21 | --- | unaffected |
firefox-esr17 | --- | wontfix |
People
(Reporter: bzbarsky, Assigned: jesup)
References
Details
(Whiteboard: [getUserMedia][blocking-gum-])
Bug 752353 unconditionally added navigator.mozGetUserMedia, with a pref that makes it a no-op if not set. But why are we exposing it at all if the pref is not set? Our current behavior causes problems like the one described in http://stackoverflow.com/questions/14236336/detecting-getusermedia-in-firefox which is pretty bad...
Assignee | ||
Comment 1•11 years ago
|
||
Note that the pref now defaults to "on" in FF20 and FF21, so this really only applies to FF18 & FF19/Beta now. (and esr17) It's still wrong if you disable the pref in FF20/21 though.
Assignee: nobody → rjesup
OS: Mac OS X → All
Priority: -- → P2
Hardware: x86 → All
Whiteboard: [getUserMedia][blocking-gum-]
Reporter | ||
Comment 2•11 years ago
|
||
Hmm. Well, we've shipped 18. So the real question is whether to fix this for 19 or not. :(
Comment 3•11 years ago
|
||
Hi I'm having the same problem which is a shame. I'd love this to be working in FF19. I'm using it in this demo which works for Chrome and Opera but has to default back to Flash for FF. http://www.craigmccahill.me.uk/index.html#mosaic The script to get it all running in FF is ready to go as soon as the default of this value changes.
Updated•11 years ago
|
status-firefox18:
--- → affected
status-firefox19:
--- → affected
status-firefox20:
--- → unaffected
status-firefox21:
--- → unaffected
status-firefox-esr17:
--- → affected
tracking-firefox19:
--- → ?
Reporter | ||
Comment 4•11 years ago
|
||
Craig, to be clear this is NOT going to be preffed on in 19. The only question is whether the property should exist there or not.
Comment 5•11 years ago
|
||
Ok that's clear thanks. I'll wait for FF20 and run with the Flash version now for FF like I'm doing for IE and Safari.
Comment 6•11 years ago
|
||
Unless we hear of significant breakage here, this is just a matter of correctness at this point (esp. since we've shipped with the incorrect behavior). We'd be willing to uplift a low risk fix, if there was no risk of new web regressions.
Reporter | ||
Comment 7•11 years ago
|
||
The main breakage is that it's making people who want to use the API have to browser-sniff instead of object-detecting, with all the ensuing bogosity...
Reporter | ||
Comment 8•11 years ago
|
||
And to be clear, I can write a patch for 19, but I'd rather not waste time doing that if we don't plan to take it.
Comment 9•11 years ago
|
||
We're preffed on in FF 20 and on for mozGetUserMedia on Desktop. No need to fix this anymore.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Updated•2 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•