User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.1 Safari/536.5 Steps to reproduce: Current implementation of HTML Media Capture is missing support for the `capture` attribute[1]. Setting the capture attribute of an INPUT type file element to "camera" should bypass the input selection menu altogether. [1]: http://www.w3.org/TR/html-media-capture/#captureparam

This is particularly important to allow web applications a credible option to take pictures.

A new testcase will need to be written, as the ones I found at: http://people.mozilla.org/~fdesre/capture/ and http://people.mozilla.org/~jhammink/webapi_test_pages/CameraAPIdemo.html don't use the "capture" attribute.

Marking dependant on bug 621915, hopefully it's not a dupe of it (hard to tell with no testcase attached to it)

Happy to provide a testcase, not sure how to test for native UI behavior however. Currently the user flow on Android nightly is: User clicks on INPUT[type=file][capture=camera] element -> opens up modal menu (with camera, camcorder, gallery, and music player options) -> user picks camera -> opens up native camera UI. Desired user flow: User clicks on INPUT[type=file][capture=camera] element -> opens up native camera UI

Wouldn't be hard to do for Android. With that being implemented, I wonder what would be the point of WebRTC's .getUserMedia()... Jonas, any thoughts?

Doesn't this disable an important functionality of android? The point of the intent system there is that users should be able to install a new camera app and have that replace the built-in app. If we always start the built-in camera app that is no longer possible. If the user want's to avoid the menu, then the user already can, by making a default choice. (Right?) Would it be possible to, when the capture attribute is set, only list camera apps rather than all apps which can supply a picture? I.e. not list gallery apps etc. And if that only results in one app we can automatically start that. And if that results in multiple apps, allow the user to remember the decision using a "select as default" checkbox.

(In reply to Jonas Sicking (:sicking) Vacation June 11-22 from comment #6) > Would it be possible to, when the capture attribute is set, only list camera > apps rather than all apps which can supply a picture? I.e. not list gallery > apps etc. And if that only results in one app we can automatically start > that. And if that results in multiple apps, allow the user to remember the > decision using a "select as default" checkbox. This is exactly what I was thinking of. Running the stock camera app without asking would be an odd behaviour and would not respect user choices.

(In reply to Mounir Lamouri (:mounir) from comment #7) > (In reply to Jonas Sicking (:sicking) Vacation June 11-22 from comment #6) > > Would it be possible to, when the capture attribute is set, only list camera > > apps rather than all apps which can supply a picture? I.e. not list gallery > > apps etc. And if that only results in one app we can automatically start > > that. And if that results in multiple apps, allow the user to remember the > > decision using a "select as default" checkbox. > > This is exactly what I was thinking of. Running the stock camera app without > asking would be an odd behaviour and would not respect user choices. Agreed. Proposed solution by Jonas (with select as default checkbox) seems ideal.

(In reply to Tobie Langel from comment #8) > (In reply to Mounir Lamouri (:mounir) from comment #7) > > (In reply to Jonas Sicking (:sicking) Vacation June 11-22 from comment #6) > > > Would it be possible to, when the capture attribute is set, only list camera > > > apps rather than all apps which can supply a picture? I.e. not list gallery > > > apps etc. And if that only results in one app we can automatically start > > > that. And if that results in multiple apps, allow the user to remember the > > > decision using a "select as default" checkbox. > > > > This is exactly what I was thinking of. Running the stock camera app without > > asking would be an odd behaviour and would not respect user choices. > > Agreed. Proposed solution by Jonas (with select as default checkbox) seems > ideal. Note that there is no real need to implement that. It should come for free with Android Intent system. We should just call in intent for ACTION_IMAGE_CAPTURE/ACTION_VIDEO_CAPTURE. I don't think there is a generic intent for capturing sounds though.

The W3C Device APIs WG is looking for Mozilla's input re implementation plans of this spec. The spec is considered stable, the test suite is approved, and the group is aware of one major shipping implementation, see: * Spec (CR): http://www.w3.org/TR/html-media-capture/ * Test suite (approved): http://w3c-test.org/html-media-capture/ * Implementation status (ships in Chrome for Android): https://www.w3.org/2009/dap/wiki/ImplementationStatus Any feedback should be provided in this bug or sent to https://lists.w3.org/Archives/Public/public-device-apis/

According to http://www.html5rocks.com/en/tutorials/getusermedia/intro/#toc-round1 "Firefox Mobile 10.0" supports the 'capture' attribute, but this is the only bug I found about implementing it and I can't tell if it was ever (partially implemented or not). Did this support somehow land in a Fennec only fork or? Regardless, regarding dev-doc-needed, I added "capture" attribute to: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input based on that html5rocks post.