serratus / quaggaJS

An advanced barcode-scanner written in JavaScript

Home Page:https://serratus.github.io/quaggaJS/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Camera direction invalid with new release

AndrePinto-NET opened this issue · comments

I saw with my Galaxy S7 Edge that with the latest release of quaggaJS, the camera is always facing the user, even if the configuration states the facing mode environment.

At the time I thought that I had some sort of error on my code, but I realized that by just doing a rollback to the previous version of quaggaJS the code works without any issue.

I was able to also reproduce the error on the live example of the project website.

It seems like the problem is not with quaggaJS but with the newest release of Chrome. I'm facing the same issues in other projects. What's your Chrome version? 53?

The version that I have on my phone is chrome 53.0.2785.124.

I have another Android phone here, so I will make a test with that one and let you know.

Yeah, that's what I thought. I'll try to track down the error and create a bug for Chrome then.

I guess you are correct, because my other phone is running version 52.0.2743.98 and there it works
Strange is that with the previous release of quaggaJs it works on Chrome v 53.

Yeah, that has to do with how I handle the available devices on the phone. The old way was deprecated a long time ago in Chrome, that's why I changed it to only use facingMode in the constraints object, which was working fine in Chrome up until v 52. But it seems like this constraint is completely ignored in Chrome v 53, alongside other constraints. You can get around that by using the following code:

navigator.mediaDevices.enumerateDevices()
  .then(devices => devices.filter(device => device.kind === 'videoinput' && device.label.indexOf('back') !== -1))
  .then(backFacingDevices => console.log(backFacingDevices.map(device => device.deviceId)))

@serratus thanks for the workaround it works as expected.

So where should I use the workaround given above?

Edit: Nevermind, got it: initialize Quagga inside the last promise.

@AndrePinto-NET I've updated the code in the master-branch with the aforementioned fix. Please give it a try and close the issue if you consider it fixed.

I've tested now and it seems to be working fine.

Thanks for your quick update.

It seems like the bug was not fixed completely, the first time we trigger a scan it opens the front camera, while the second trigger opens the back camera

Someone has it working?

commented

Has someone gotten this to work? testing on my android phone and it is always picking the user facing camera even though the facingMode = "environment". I noticed that at least on my phone when doing the enumerateDevices the user camera is been returned first.

works as expected here with my Nexus 5, recently ran through it on Android 5, 6, 7, and 8 on that device. at least, with facingMode = 'environment', haven't tried the other way.

it's a bit messy to figure out with extensive use of jQuery (wow, reading jQ code is obnoxious), but there is manual camera selection code in https://github.com/serratus/quaggaJS/tree/master/example in live_w_example .. it looks like you get the camera id from enumerateDevices() and then pass it to Quagga.init() as inputStream.constraints.deviceId . . . .

I had this issue recently in a Cordova app which used Crosswalk v23 and was thus provided with Chromium 53. The workaround suggested by @serratus works for me.

PS: I also tested this workaround outside of Crosswalk, for example on an iPhone in mobile Safari and there I noticed that the label was being translated to whatever language my phone was set to (Dutch in my case). So this might be something you have to take into account.

facingMode was deprecated quite some time ago, you should be using individual camera selection. However, Android Chrome won't prompt for camera access when you enumerateDevices(), it only prompts when you actually attempt to open the camera. This means you can't get permissions to enumerate, until after you've already tried to use the camera once.

Not much we can do about that, but it leaves end users requiring an odd set of hoops to go through.