Some background info - Bug 771248 enabled building WebRTC by default in nightly. Bug 691234 added navigator.mozGetUserMedia() support. The user needs to change an about:config pref to use mozGetUserMedia. Recommendation - When Firefox 16 becomes Aurora, we should disable building WebRTC and mozGetUserMedia. Here's why: * The footprint increase is significant(about 1.5MB) and for most users, they aren't getting much return for the increase. mozGetUserMedia is the only piece of WebRTC that a developer can really play with, and it's still being debugged and developed. * We want developers and testers using the latest and greatest code (i.e. nightly) and having the feature in Aurora means there's the possibility that some devs may develop and test against old code. It's likely the mozGetUserMedia code in Aurora will be quite stale within a few weeks of uplift. * We don't want the added burden of patching or fixing mozGetUserMedia bugs found in Aurora. We want to fix them in nightly and move on IMO. Having mozGetUserMedia/WebRTC only in nightly achieves what we want and won't impact our end users.
Firefox 16 is now on Aurora channel.
Created attachment 643063 [details] [diff] [review] Disable webrtc and mozGetUserMedia for Aurora Cut at a patch, currently against inbound, will need rebasing against aurora - my pull of Aurora didn't have the uplift yet
Comment on attachment 643474 [details] [diff] [review] Disable webrtc and mozGetUserMedia for Aurora [Approval Request Comment] Bug caused by (feature/regressing bug #): n/a User impact if declined: extra download and code size for all desktop users; users trying mozGetUserMedia on a stale version as it's under active development. Testing completed (on m-c, etc.): https://tbpl.mozilla.org/?tree=Try&rev=dfe55676b796 (searching by pusher may work better). Previously ran the same patch (r+'d by ted) through a try run against inbound. Risk to taking this patch (and alternatives if risky): Almost no risk, since we're disabling stuff only visible if you flip an about:config pref, and the visible portion (mozGetUserMedia) was only just landed. String or UUID changes made by this patch: None carrying forward r=ted (just rebased onto current aurora)
Holding on the patch because of orange/red on Android (build is green): https://tbpl.mozilla.org/?tree=Try&rev=3a94fa1c6f5e or https://tbpl.mozilla.org/?tree=Tryemail@example.com and click down a ways. Unfortunately the try logs don't tell me anything useful about why the tests didn't run. Looking at patches to figure out what the entanglement is that was introduced.
I pointed jmaher at these logs, and it appears this is just a symptom of pushing aurora to try. The Fennec package name on Aurora is org.mozilla.fennec_aurora, which is not what the automation expects, so it fails to launch the process. You should be able to ignore that.
Ok, that resolves my concern. https://hg.mozilla.org/releases/mozilla-aurora/rev/13235b7f1267
Also, I downloaded the try build and installed it on my Galaxy Tab and it worked fine.
(In reply to Randell Jesup [:jesup] from comment #7) > Ok, that resolves my concern. > > https://hg.mozilla.org/releases/mozilla-aurora/rev/13235b7f1267 Got failures on windows: https://tbpl.mozilla.org/php/getParsedLog.php?id=13909672&tree=Mozilla-Aurora https://tbpl.mozilla.org/php/getParsedLog.php?id=13909848&tree=Mozilla-Aurora Clobbered and retriggered to see if that fixes it. Have closed the tree in the meantime. It's coming up to evening for me, so would you be ok to check back in 2 hours when the builds finish - then backout if needs be & set the tree back to approval required?
This patch seems to still be in Beta (16), so I assume the retrigger worked (long enough ago I can't remember if I checked). But if it was backed out that should be noted here, and it doesn't appear to be. So this bug should be closed. A separate issue is we should consider disabling mozGetUserMedia in Aurora (17), but the argument for disabling it is slightly weaker, as it had another 6 weeks of testing. It is still behind a pref, though, so it would mostly be for developers to play with - but 3rd-parties on the web are starting to modify demos for FF, and nightlies are a bigger hump to get people to use than Aurora.
(In reply to Randell Jesup [:jesup] from comment #10) > This patch seems to still be in Beta (16), so I assume the retrigger worked > (long enough ago I can't remember if I checked). But if it was backed out > that should be noted here, and it doesn't appear to be. So this bug should > be closed. Marking FF16 as fixed since we think this work is done.
Didn't get closed when this landed on Aurora