Created attachment 8546727 [details] [diff] [review] undo_d26db5427e8a.patch STR: 1. On a Windows box with an HD webcam (like Logitech C910 or higher) 2. Open URL 3. Hit [Start!] button and share the camera. Expected result: - Success: 1280x720 Actual result: - Success: 640x480 Tests performed: Windows 7 FF 32.0: Success: 1280x720 (good) Windows 7 FF 34.05: Success: 640x480 (bad) mozregression only got me so far on my Windows setup: Last good revision: 0aaa2d3d15cc First bad revision: 111a1da2a95d The culprit is https://hg.mozilla.org/integration/mozilla-inbound/rev/d26db5427e8a I've attached a reverse patch of that commit and verified that it fixes this bug on my Windows 7 machine. Thanks Florin for catching this in Bug 1094539 comment 17! I'll try to work on some automated tests so this doesn't keep breaking every few months. :-/
Ugh, let's see if we can fix the bug in that patch because regressing 929431 renders WebRTC (and by extension Loop) unusable for a lot of people.
Created attachment 8547462 [details] [diff] [review] fix-requestedcapability
Comment on attachment 8547462 [details] [diff] [review] fix-requestedcapability Approval Request Comment [Feature/regressing bug #]: Bug 929431 [User impact if declined]: WebRTC width/height constraints not taken into account on Windows [Describe test coverage new/current, TBPL]: None, landed on m-c +- week ago [Risks and why]: Worst case some cameras with bad drivers will be slower starting a WebRTC session or break completely. [String/UUID change made/needed]: None
Reproduced on Nightly 2015-01-09, Windows 7 x64, with str from comment 0 - Success: 640x480 is displayed. Verified as fixed on 36.0 beta 3 (Build ID: 20150122214638), Aurora 37.0a2 (Build ID: 20150125004007) and Nightly 38.0a1 (Build ID: 20150125030202) with e10s enabled/disabled.