"Upload an image" dialog opens gallery only (no camera) on Chromium-based Android browsers

[mtnholt]

• I have searched for similar issues in both open and closed tickets and cannot find a duplicate.
• I have read the documentation and cannot find an answer.

Describe the issue
The built-in "Upload an image" dialog's device-upload field is a plain <input type="file" accept="image/*"> with no capture attribute. On Samsung Internet and iOS Safari, the OS still offers a "camera" option for this input, but on Chromium-based Android browsers (Chrome specifically) the input only opens the device gallery/file picker, with no way to trigger the camera directly. This is inconsistent behavior across mobile browsers for what is meant to be the same "upload an image" action.

Reproduction
The public demo at https://mdxeditor.dev/editor/demo reproduces this too, since it uses the same default image dialog.

To Reproduce
Steps to reproduce the behavior:

1. Open https://mdxeditor.dev/editor/demo on an Android phone using Chrome.
2. Click the "Insert image" toolbar button.
3. In the "Upload an image" dialog, click "Choose File".
4. The device gallery/file picker opens directly; there is no option to open the camera.
5. Repeat the same steps on the same device using Samsung Internet, or on an iOS phone using Safari: the camera option is offered there.

See attached unwanted_behaviour.gif (Chrome on Android: gallery only) vs. wanted_behaviour.gif (Samsung Internet: camera option available).

Unwanted (Chrome on Android: gallery only)	Wanted (Samsung Internet: camera option available)

Expected behavior
The device-upload field should consistently offer the option to take a photo directly with the camera, regardless of browser. Since this is a common web-platform gotcha (the fix is adding capture="environment" to the file input), it would help if imagePlugin exposed an option to add this attribute to the built-in dialog's file input, e.g.:

imagePlugin({
  imageUploadHandler,
  captureAttribute: 'environment', // or 'user', or undefined to keep current behavior
})

Screenshots
See attached wanted_behaviour.gif and unwanted_behaviour.gif.

Mobile (please complete the following information):

• OS: Android (issue reproduces), iOS (works correctly)
• Browser: Chrome on Android (issue reproduces); Samsung Internet on Android and Safari on iOS (both work correctly, camera option offered)

Additional context
As a workaround, we added a second toolbar button next to the existing "insert image" button. It uses a hidden <input type="file" accept="image/*" capture="environment">, and on change calls the public insertImage$ signal with the selected file, so it goes through the same imageUploadHandler pipeline as a normal image insert. This reliably opens the camera across Chrome Android, Samsung Internet, and iOS Safari, confirming capture="environment" is the fix.
It would be nice to have this built into the default dialog/plugin options rather than requiring a separate button.

[petyosi]

Thanks for the detailed report and the reproduction — the inconsistency is real, and the analysis below explains why I'm keeping the issue open but not implementing the proposed captureAttribute option as-is.

Why a captureAttribute option would mislead more than it helps

The capture attribute doesn't add a camera option to the file picker — it replaces the picker with direct capture. The W3C HTML Media Capture spec describes it as expressing "a preference for the user agent to directly capture media of a certain type from a capture mechanism, instead of allowing the user to pick from an existing file", with the normative clause:

When the capture attribute is specified, the user agent SHOULD invoke a file picker of the specific capture control type.

Both major mobile engines implement that literally: with capture="environment" set, Chrome on Android and Safari on iOS launch the camera directly, and the gallery option disappears. You can verify this on the HTML Media Capture test bench (linked from caniuse). Note that MDN's description is looser ("selection from an existing file or the creating of a new one") — it doesn't match observed behavior on either engine.

So a plugin-level captureAttribute option would:

• not achieve the goal on Chrome Android (camera instead of gallery, not camera alongside gallery), and
• regress iOS Safari and Samsung Internet, where the chooser currently offers both.

Your own workaround points at the correct UX: a second, camera-only affordance next to the regular file input. A single input can't offer both paths on Chromium Android — that chooser is browser UI, not something the page can request.

What's available today

The dialog is replaceable wholesale: imagePlugin({ ImageDialog: MyDialog }). Everything the built-in dialog uses is public API — imageDialogState$, saveImage$, closeImageDialog$, imageUploadHandler$, imageAutocompleteSuggestions$ — so a custom dialog can render both a regular file input and a "Take photo" input with capture="environment", and publish the result through the same saveImage$ / insertImage$ pipeline (as your workaround already does).

This is admittedly the harder path: the built-in dialog's internal pieces (the src autocomplete component and the CSS module styles) aren't exported, so it's a rebuild of the dialog UI rather than a copy with one extra attribute. That's a deliberate trade-off — the plugin's customization surface is component-level (ImageDialog, EditImageToolbar, imagePlaceholder) rather than a growing list of attribute-level knobs.

Keeping this open

The legitimate gap is that the default dialog has no camera affordance on Chromium Android at all. The direction I'd consider is an intent-level option (e.g. an opt-in "take photo" field rendered alongside the existing upload field, only when imageUploadHandler is configured) rather than a raw attribute pass-through. Leaving this open to track that.

[mtnholt]

Thanks for the detailed explanation, that clears up why a raw captureAttribute pass-through wouldn't actually work as intended.

I actually put together a small POC exploring both directions you outlined before posting this issue.
Live demo here: https://mtnholt.github.io/mdxeditor-poc/ (repo: https://github.com/mtnholt/mdxeditor-poc)

• Variant A: a separate "Take photo" button in the toolbar, next to "Insert image". Uses only the public insertImage$ signal, so it goes through the existing imageUploadHandler pipeline unchanged. This is the workaround I originally described in the issue.

• Variant B: a custom ImageDialog that adds a "Take photo" button inside the "Upload an image" dialog itself, alongside the regular device-upload field. Built entirely on the public API you mentioned (imageDialogState$, saveImage$, closeImageDialog$), no internal pieces needed.

Both use a second hidden file input with capture="environment" for the camera-only path, so the regular field keeps offering gallery/file picker as before.

Note that the styling on Variant B is just meant for testing the UX here, not something I'd propose as-is for the built-in dialog's look and feel. The point was to validate the interaction pattern (two separate affordances) rather than to nail the visual design.

Tested on iPhone 17 with Safari, and on Samsung devices with both Chrome and the built-in "Internet" browser. Camera capture worked consistently across all of them.

My own preference would be Variant B for the actual product, though we're currently running Variant A in our own instance.

Feel free to use any of this code as a starting point if it's useful for landing this in the default dialog. Happy for you (or anyone) to take this and turn it into a PR.