Support camera capture for <input type=file capture> on desktop [chromium/src : main]
Helmut Januschka (Gerrit)
Message from Helmut Januschka![]( "Open in Gerrit")
Set Ready For Review
Related details
- Helmut Januschka
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Yoav Weiss (@Shopify) (Gerrit)
Yoav Weiss (@Shopify) added 2 comments![]( "Open in Gerrit")
Elad - do you know who would be a good reviewer for the UI parts?
status: "stable",I think you want to mark desktop as experimental here
Related details
- Elad Alon
- Helmut Januschka
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
Can you point to the spec for this?
Also, you would need an Intent to Ship to enable this by default.
Related details
- Helmut Januschka
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Helmut Januschka (Gerrit)
Helmut Januschka added 2 comments![]( "Open in Gerrit")
Can you point to the spec for this?
Also, you would need an Intent to Ship to enable this by default.
documentation: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/file#capture
spec: https://w3c.github.io/html-media-capture/#dfn-capture
I2P posted on blink dev and chromestatus feature entry: https://chromestatus.com/feature/5154771310870528
I think you want to mark desktop as experimental here
- Guido Urdaneta
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
Harald, is this something we should be adding support for?
It's not clear to me that this spec is even maintained.
Related details
- Harald Alvestrand
- Helmut Januschka
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Harald Alvestrand (Gerrit)
Harald Alvestrand added 1 comment![]( "Open in Gerrit")
argument for cross-platform compatibility ("Android alredy does this") seems pretty compelling to me.
Do we have UMA that shows that the Android feature is in fact used?
(No comments on the code. It doesn't seem to touch on the webrtc-related code paths.)
(Parenthetical: This seems to involve writing video to a temporary file, which is a standing invitation to a disk space exhaustion attack. Is the feature adequately guarded against this kind of abuse?)
Related details
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
ellyjones@: Please take a look at chrome/browser/ui
tungnh@ for permissions/security review
Related details
- Elly FJ
- Helmut Januschka
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
blundell@: Please take a look at chrome/browser
Related details
- Colin Blundell
- Elly FJ
- Helmut Januschka
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Colin Blundell (Gerrit)
Colin Blundell added 1 comment![]( "Open in Gerrit")
Hi,
Thanks! This CL is very large. Is it possible to break it up?
It also looks like trybots are unhappy.
Related details
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
Harald, is this something we should be adding support for?
It's not clear to me that this spec is even maintained.
Closing comment, as already replied.
Related details
- Elly FJ
- Helmut Januschka
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
Note also that there is a <usermedia> element proposal in development that overlaps a bit with this one. See https://github.com/WICG/PEPC/blob/main/usermedia_element.md
Related details
- Elly FJ
- Helmut Januschka
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Elly FJ (Gerrit)
Elly FJ added 1 comment![]( "Open in Gerrit")
I am happy to review this but to guidou@'s question, do we want this feature? Is the relevant spec mature, supported elsewhere, etc?
Related details
Helmut Januschka (Gerrit)
Helmut Januschka added 3 comments![]( "Open in Gerrit")
Hi,
Thanks! This CL is very large. Is it possible to break it up?
It also looks like trybots are unhappy.
working on trybot (seems to be false positive on wayland-mutter)
i have no problem with splitting, but would really love to do this at a stage where the direction is clear, otherwise splitting (and keeping split's alive) is painfull (atleast for me)
argument for cross-platform compatibility ("Android alredy does this") seems pretty compelling to me.
Do we have UMA that shows that the Android feature is in fact used?(No comments on the code. It doesn't seem to touch on the webrtc-related code paths.)
(Parenthetical: This seems to involve writing video to a temporary file, which is a standing invitation to a disk space exhaustion attack. Is the feature adequately guarded against this kind of abuse?)
good point about the diskspace exhaustion, going to find similar places how they guard!
Note also that there is a <usermedia> element proposal in development that overlaps a bit with this one. See https://github.com/WICG/PEPC/blob/main/usermedia_element.md
thanks will try to understand how much of a intersection this has.
Related details
- Colin Blundell
- Guido Urdaneta
- Harald Alvestrand
Colin Blundell (Gerrit)
Colin Blundell added 1 comment![]( "Open in Gerrit")
Helmut JanuschkaHi,
Thanks! This CL is very large. Is it possible to break it up?
It also looks like trybots are unhappy.
working on trybot (seems to be false positive on wayland-mutter)
i have no problem with splitting, but would really love to do this at a stage where the direction is clear, otherwise splitting (and keeping split's alive) is painfull (atleast for me)
Thanks, that makes sense! In that case I defer to the folks more closely involved here - would you mind taking me off the CL for now and adding me back if/when it's at the stage where what's remaining is just whatever relevant OWNERS bits for peripheral files?
Related details
- Guido Urdaneta
- Harald Alvestrand
- Helmut Januschka
Helmut Januschka (Gerrit)
Helmut Januschka added 1 comment![]( "Open in Gerrit")
Helmut JanuschkaHi,
Thanks! This CL is very large. Is it possible to break it up?
It also looks like trybots are unhappy.
Colin Blundellworking on trybot (seems to be false positive on wayland-mutter)
i have no problem with splitting, but would really love to do this at a stage where the direction is clear, otherwise splitting (and keeping split's alive) is painfull (atleast for me)
Thanks, that makes sense! In that case I defer to the folks more closely involved here - would you mind taking me off the CL for now and adding me back if/when it's at the stage where what's remaining is just whatever relevant OWNERS bits for peripheral files?
- Guido Urdaneta
- Harald Alvestrand
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
Before we continue, what use case do you intend to support with this API that is not already well supported with getUserMedia and Media Recorder, or the upcoming usermedia element?
Related details
- Harald Alvestrand
- Helmut Januschka
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Helmut Januschka (Gerrit)
Helmut Januschka added 1 comment![]( "Open in Gerrit")
Before we continue, what use case do you intend to support with this API that is not already well supported with getUserMedia and Media Recorder, or the upcoming usermedia element?
use case is the quick "take photo and upload" flow for `<input type="file" accept="image/*" capture>` in ordinary form journeys (KYC, receipts, support photos, etc.).
I agree this overlaps partly with `getUserMedia` and the proposed `<usermedia>` element in PEPC, but the overlap is mostly at stream control.
What is still missing for this specific journey is a simple capture-to-file path integrated with file upload:
- one-step UX from file input intent
- no custom camera app UI in page JS
- no manual stream lifecycle + capture + conversion to `File`
- behavior that matches native file upload expectations across platforms
So the intent here is not to replace stream APIs. It is to support the `capture`-on-file-input workflow directly, with a native-feeling cross-platform path and better interop.
Related details
- Guido Urdaneta
- Harald Alvestrand
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
Helmut JanuschkaBefore we continue, what use case do you intend to support with this API that is not already well supported with getUserMedia and Media Recorder, or the upcoming usermedia element?
use case is the quick "take photo and upload" flow for `<input type="file" accept="image/*" capture>` in ordinary form journeys (KYC, receipts, support photos, etc.).
I agree this overlaps partly with `getUserMedia` and the proposed `<usermedia>` element in PEPC, but the overlap is mostly at stream control.
What is still missing for this specific journey is a simple capture-to-file path integrated with file upload:
- one-step UX from file input intent
- no custom camera app UI in page JS
- no manual stream lifecycle + capture + conversion to `File`
- behavior that matches native file upload expectations across platforms
So the intent here is not to replace stream APIs. It is to support the `capture`-on-file-input workflow directly, with a native-feeling cross-platform path and better interop.
Can you update the design doc and explain how this use case is better supported with this API than with getUserMedia + image capture (grabFrame/takePhoto) and why it is worth the extra maintenance burden?
(for example, https://googlechrome.github.io/samples/image-capture/grab-frame-take-photo.html)
It would be useful to compare https://googlechrome.github.io/samples/image-capture/grab-frame-take-photo.html with a similar demo using this API as supported on other browsers.
Related details
- Harald Alvestrand
- Helmut Januschka
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Helmut Januschka (Gerrit)
Helmut Januschka added 1 comment![]( "Open in Gerrit")
Helmut JanuschkaBefore we continue, what use case do you intend to support with this API that is not already well supported with getUserMedia and Media Recorder, or the upcoming usermedia element?
Guido Urdanetause case is the quick "take photo and upload" flow for `<input type="file" accept="image/*" capture>` in ordinary form journeys (KYC, receipts, support photos, etc.).
I agree this overlaps partly with `getUserMedia` and the proposed `<usermedia>` element in PEPC, but the overlap is mostly at stream control.
What is still missing for this specific journey is a simple capture-to-file path integrated with file upload:
- one-step UX from file input intent
- no custom camera app UI in page JS
- no manual stream lifecycle + capture + conversion to `File`
- behavior that matches native file upload expectations across platforms
So the intent here is not to replace stream APIs. It is to support the `capture`-on-file-input workflow directly, with a native-feeling cross-platform path and better interop.
Can you update the design doc and explain how this use case is better supported with this API than with getUserMedia + image capture (grabFrame/takePhoto) and why it is worth the extra maintenance burden?
(for example, https://googlechrome.github.io/samples/image-capture/grab-frame-take-photo.html)It would be useful to compare https://googlechrome.github.io/samples/image-capture/grab-frame-take-photo.html with a similar demo using this API as supported on other browsers.
Sure, I will update the design doc with a dedicated comparison section.
In the meantime, I put together a live side-by-side demo that compares the getUserMedia + ImageCapture path with `<input capture>`:
https://static.januschka.com/i-40291635/demo.html
Key points the demo illustrates:
- getUserMedia + ImageCapture requires ~50 lines of JS: custom camera UI, stream lifecycle management, error handling for 5+ error types, and a DataTransfer hack to inject the Blob into a form input.
- `<input type="file" accept="image/*" capture>` requires 1 line of HTML and 0 lines of JS. Browser handles permission, camera UI, capture, and file creation. The result lands directly in the file input, and FormData / form submission just works.
- ImageCapture itself is Chrome-only, so using it as the "simple" path for web developers is not cross-browser. `<input capture>` already works on mobile (Android Chrome, Firefox, Safari iOS) but no desktop browser supports it yet -- this CL would make Chrome the first.
The two APIs serve different needs: getUserMedia/ImageCapture is right for video conferencing, AR/ML, and custom camera UX. `<input capture>` targets the quick "snap a photo and upload" form workflow (KYC, receipts, support tickets) where the developer should not need to build a camera app.
Related details
- Guido Urdaneta
- Harald Alvestrand
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
Helmut JanuschkaBefore we continue, what use case do you intend to support with this API that is not already well supported with getUserMedia and Media Recorder, or the upcoming usermedia element?
Guido Urdanetause case is the quick "take photo and upload" flow for `<input type="file" accept="image/*" capture>` in ordinary form journeys (KYC, receipts, support photos, etc.).
I agree this overlaps partly with `getUserMedia` and the proposed `<usermedia>` element in PEPC, but the overlap is mostly at stream control.
What is still missing for this specific journey is a simple capture-to-file path integrated with file upload:
- one-step UX from file input intent
- no custom camera app UI in page JS
- no manual stream lifecycle + capture + conversion to `File`
- behavior that matches native file upload expectations across platforms
So the intent here is not to replace stream APIs. It is to support the `capture`-on-file-input workflow directly, with a native-feeling cross-platform path and better interop.
Helmut JanuschkaCan you update the design doc and explain how this use case is better supported with this API than with getUserMedia + image capture (grabFrame/takePhoto) and why it is worth the extra maintenance burden?
(for example, https://googlechrome.github.io/samples/image-capture/grab-frame-take-photo.html)It would be useful to compare https://googlechrome.github.io/samples/image-capture/grab-frame-take-photo.html with a similar demo using this API as supported on other browsers.
Sure, I will update the design doc with a dedicated comparison section.
In the meantime, I put together a live side-by-side demo that compares the getUserMedia + ImageCapture path with `<input capture>`:
https://static.januschka.com/i-40291635/demo.htmlKey points the demo illustrates:
- getUserMedia + ImageCapture requires ~50 lines of JS: custom camera UI, stream lifecycle management, error handling for 5+ error types, and a DataTransfer hack to inject the Blob into a form input.
- `<input type="file" accept="image/*" capture>` requires 1 line of HTML and 0 lines of JS. Browser handles permission, camera UI, capture, and file creation. The result lands directly in the file input, and FormData / form submission just works.
- ImageCapture itself is Chrome-only, so using it as the "simple" path for web developers is not cross-browser. `<input capture>` already works on mobile (Android Chrome, Firefox, Safari iOS) but no desktop browser supports it yet -- this CL would make Chrome the first.
The two APIs serve different needs: getUserMedia/ImageCapture is right for video conferencing, AR/ML, and custom camera UX. `<input capture>` targets the quick "snap a photo and upload" form workflow (KYC, receipts, support tickets) where the developer should not need to build a camera app.
After an internal discussion, we decided that it's OK to proceed with this.
Please split in smaller CLs for easier review.
Related details
- Harald Alvestrand
- Helmut Januschka
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Helmut Januschka (Gerrit)
Helmut Januschka added 1 comment![]( "Open in Gerrit")
@gui...@chromium.org done, splittet it into 4, and also started polishing and changed window type to tab-modal see topic: https://chromium-review.googlesource.com/q/topic:%22hja_media_capture%22
should i send it to review, or is there any other next step, really appreciate your guidance?
Related details
- Guido Urdaneta
- Harald Alvestrand
Guido Urdaneta (Gerrit)
Guido Urdaneta added 1 comment![]( "Open in Gerrit")
Start sending the CLs for review. Add a reference to the design doc in all reviews and also a reference to the chromestatus.com entry.
Keep everything behind a flag disabled by default (you can use the MediaCapture base::Feature generated automatically by runtime_enabled_flags.json5).
Before enabling by default, you might need some additional reviews in chromestatus.com, but that's normally not a blocker to start landing code disabled by default.
Related details
- Harald Alvestrand
- Helmut Januschka
Helmut Januschka (Gerrit)
Helmut Januschka abandoned this change.
Helmut Januschka abandoned this change![]( "Open in Gerrit")
Related details
Code-Coverage
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Helmut Januschka (Gerrit)
Helmut Januschka added 1 comment![]( "Open in Gerrit")
splitted and sent CL's - going to abandon this one
@gui...@chromium.org - let me really thank you appreciate the help and the opportunity to give it a try!!
Related details
- Guido Urdaneta
- Harald Alvestrand
- Thomas Nguyen
- Yoav Weiss (@Shopify)
Code-Coverage
Code-Owners
Code-Review
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |