Judy notes:

I reviewed the js for camera in IF4 (trunk). It basically just calls the navigator.getUserMedia(options, successCallback, errorCallback);
Which according to this:
https://developer.mozilla.org/en/docs/Web/API/Navigator/getUserMedia
Has been deprecated and replaced by
MediaDevices.getUserMedia....
Of course, there is backwards capability, but the newer calls has an api to flip the camera, so if the 8 inch tablet is newer, it may be considering that the js is the newer api.

<input type="file" accept="image/*"> should just work now without requiring getUserMedia, though we might still need to test if the browser has support for this feature. somehow

It looks like the WIn 10 Edge browser does support the navigator.mediaDevices.getUserMedia() API, including both the older callback API and the newer promise-based API. It also supports the "facingMode" configuration parameter, so should be good to support the desired use-case.

Reference: https://blogs.windows.com/msedgedev/2015/05/13/announcing-media-capture-functionality-in-microsoft-edge/

I think the work here is to add a button to the fallback HTML5 camera that can toggle the camera between the front "user" camera and the rear "environment" camera when running on a mobile device.

Example:

on mobile devices, the following will prefer the front camera (if one is available) over the rear one:

{ audio: true, video: { facingMode: "user" } }
To require the rear camera, use:

{ audio: true, video: { facingMode: { exact: "environment" } } }

r49363: added button to toggle between front and back cameras in the fallback HTML5 camera interface

I added the button to toggle between cameras in the HTML5 camera interface. However, I haven't been able to test it correctly, since the Media Capture Stream (getUserMedia) API is not supported on iOS (http://mobilehtml5.org/), and the only mobile device I can test this at the moment is an iPhone. If we want to support this feature on Bridgeit, then the Bridgeit app would have to be modified, in order to invoke the right commands and options and to show the toggle button. I could only test this on desktop browsers, but since my laptop only has one camera, I couldn't see the camera actually toggling, but the button is there, and clicking it causes to re-render the dialog specifying a different camera, according to the Media Stream API (https://w3c.github.io/mediacapture-main/getusermedia.html).

Testing notes: please test this feature in any way possible with the mobile devices you have available

Tested with ICEfaces 4 trunk r 49364 using Android 6.0.1 Nexus 5 and showcase camera demo. The toggling of front and back cameras worked properly. The thumbnails were present and I was able to upload the files successfully.

Art will investigate to see if there is a reliable way to determine if more than one camera exists on the device which would allow the component to not render the camera toggle button if only a single camera is available.

There's no reliable way of determining if a device has both front and back cameras.

The MediaStream API supports the method navigator.mediaDevices.enumerateDevices(), which returns a Promise object that must be resolved. Once resolved, an array of MediaDeviceInfo objects is obtained, containing data about all the devices in the system. However, this information is highly dependent on the device itself and on the user agent implementation of the API. The only clue we have to know if a device is a camera is the 'kind' property in the MediaDeviceInfo object, which can have a value of 'videoinput':
https://w3c.github.io/mediacapture-main/getusermedia.html#dom-mediadevicekind-videoinput

In the tests I made I found that there's no other information given about whether it's actually a camera or some other type of video input or about the location of this camera, which could simply be an additional, external webcam.

The algorithm would consist of simply checking to see if there are at least two 'videoinput' devices for rendering the toggle button, but as mentioned above, there's no reliable way of knowing if the device actually has both front and back cameras.

I guess it would work in most cases, and in some cases the button would be rendered even if there are no front and back cameras, but simply an integrated and an external camera.

Another way of approaching this is to avoid rendering this button if there's only one 'videoinput' device.

Another way of approaching this is to avoid rendering this button if there's only one 'videoinput' device.

I think this is a useful approach. That way it won't confuse users on desktops, etc. with only a single camera available.

r49381: added code to only display the toggle camera button if the system has more than one 'videoinput' devices, presumably cameras

Testing Notes: On laptops and desktops this button shouldn't be rendered. On mobile devices with front and back cameras, this button should be rendered (except for iOS devices, which don't support this API).

Verified using showcase camera demo, ICEfaces 4 trunk r49382, Tomcat 8, Android 6.0.1 nexus 5 phone, IE 11, MS edge, Chrome 53, FF 47.

Re-opened. It turns out that due to a lack of communication on my part the verification for this feature on Android actually used the BridgeIt camera, not the HTML5 camera. Thus, we haven't been able to verify that the camera is actually toggling between front/back as desired, since all the none-mobile platforms we've used only have a single camera attached.

We'll need to re-think the current mobi:camera behavior to force BridgeIt to be used when on mobile platforms before we can verify this further. That will be tackled under new JIRAs.

New JIRA to re-implement the HTML5 camera.

Closing as duplicate.