Tobie Langel Reporter
	Description • 12 years ago

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

	Tobie Langel Reporter
	Comment 1 • 12 years ago

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

	Mardeg
	Comment 2 • 12 years ago

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.

	Mardeg
	Comment 3 • 12 years ago

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

	Tobie Langel Reporter
	Comment 4 • 12 years ago

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

	Mounir Lamouri (:mounir)
	Comment 5 • 12 years ago

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?

	Jonas Sicking (:sicking) No longer reading bugmail consistently
	Comment 6 • 12 years ago

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.

	Mounir Lamouri (:mounir)
	Comment 7 • 12 years ago

(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.

	Tobie Langel Reporter
	Comment 8 • 12 years ago

(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.

	Mounir Lamouri (:mounir)
	Comment 9 • 12 years ago

(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.

	Anssi Kostiainen
	Comment 10 • 9 years ago

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/

	Tantek Çelik
	Comment 11 • 8 years ago

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.