That's odd, I'm running ToT practically every day and
didn't have issues capturing. What's the hardware that
doesn't work? Is it also verifiable with [1]?

[1] https://rawgit.com/Miguelao/demos/master/gum_simple.html

This is on a Samsung Galaxy S7. I just double-checked the urls and the ones in the first post are still broken, but your sample works. Maybe we changed an API?

#2: I think I know what the problem is, the code is falling
through  navigator.getUserMedia(videoObj, ...);
instead of using  navigator.webkitGetUserMedia(...), the 
former is promise based and the latter is old-school 
asynchronous functions.

Not 100% sure if you need 
chrome://flags/#enable-experimental-web-platform-features
enabled for the promise-based gUM to work, but probably
you have that one on :)

(forgot to say #4 refers to the code in https://jsbin.com/saxoye/edit)

Btw, for snapping a picture, you can also consider
takePhoto() or grabFrame() [2] directly on the MediaStream,
saving you the round trip through canvas :)

[1] https://github.com/miguelao/demos/blob/master/imagecapture.html#L63
[2] https://github.com/miguelao/demos/blob/master/imagecapture.html#L90

This seems to have broken many real websites. Do we know the scale of the breakage? These sites still work in Firefox.

I think we should reconsider WontFix.

Adding some peeps to respond to the question in #6, 
hta@, guidou@, foolip@, WDYT? Do we have metrics of
the new API usage?

Ping?

navigator.getUserMedia is actually not promise-based, it has the same success/error callback pair as navigator.webkitGetUserMedia. (navigator.mediaDevices.getUserMedia is promise-based.)

AFAICT, the problem in both https://webqr.com/ and https://jsbin.com/saxoye/edit?html,console,output is that video.src is assigned differently in both cases. When the prefixed API is used, webkitURL.createObjectURL is used, but when the unprefixed API is used, video.src is just set to the stream object.

IIRC, at some point in the discussion that led up to video.srcObject there was the suggestion to just allow setting video.src, but I don't think that ended up implemented anywhere. For whatever reason, this script mistakenly assumes that it's possible to set video.src to a MediaStream, and that can't be fixed.

Without changing the script, the only thing that could be done is to unship navigator.getUserMedia.

Do we have any clue about how common this problem is? pdr@, do you know of other cases?

Usage of this API is at https://www.chromestatus.com/metrics/feature/timeline/popularity/1401 but that doesn't say much about the prevalence of this coding mistake.

Thanks foolip. I got the code for that jsbin from the first hit on google for "html5 camera demo", https://davidwalsh.name/browser-camera. https://www.the-qrcode-generator.com/scan and the HTML5Rocks demos are broken too.

Maybe we could just update our docs (html5 rocks) and reach out to these sites?

http://www.html5rocks.com/en/tutorials/getusermedia/intro/ doesn't seem to have this specific problem in the article, but the demo fails at "navigator.getUserMedia('video', ...)" because "TypeError: Failed to execute 'getUserMedia' on 'Navigator': parameter 1 ('options') is not an object."

And then it actually would assign video.src = stream if it hadn't already failed.

pdr@, did you just stumble upon these sites, or did you search in a corpus? In other words, is this just the tip of the iceberg? I think we should be quite willing to revert navigator.getUserMedia, because navigator.mediaDevices.getUserMedia was also added at the same time and is the API that we "want" people to use as the first choice.

guidou@, hta@, thoughts?

foolip@, I stumbled on the QR sites during regular browsing; was trying to find a QR reader for testing my homepage. The jsbin repro I used was just naively copying code from the first hit on google (David Walsh's blog). There's a chance I just got unlucky.

So the problem in the initial snippet is this:

if(navigator.getUserMedia) { // Standard
				navigator.getUserMedia(videoObj, function(stream) {
					video.src = stream;
					video.play();
				}, errBack);

The author wrote the code from what he imagined the standard would be. It never worked, in any browser. Perhaps there was a version of the standard that specified video.src = track; I know it was discussed on the list, but I can't remember ever publishing a version that had it.

Now the standard has changed from what he once thought it would be. And his trigger for "it claims to conform to the standard" has triggered.
The code has a bug.
I don't think we should revert because of a bug.

Similarly, line 798 of http://www.html5rocks.com/en/tutorials/getusermedia/intro/ has a pure bug: He forgot to put the {} around "video: true". Again, code never executed, not tested, has a bug.

I think we can't protect buggy code from itself forever. And given that the amount of code yet to be written is larger than the amount of code currently written, I think the Right Thing is to get the standards-compliant stuff out there ASAP, and let the bugs be found.

Thanks for looking into this! It sounds like WontFix was the correct decision all along.

I will shoot off an email to Eric (html5rocks author) and do my best to contact the QR code sites as well.

If this pops up again and someone finds this issue, please comment so that we can consider whether the compat fallout is worth it.