Closed Bug 795013 Opened 7 years ago Closed 7 years ago

accepts attribute not working correctly on input elements

Categories

(Firefox for Android :: General, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 18

People

(Reporter: wesj, Assigned: wesj)

Details

Attachments

(3 files)

See:

http://robnyman.github.com/camera-api/

Tapping the input should show only activities that can send back images. Right now it shows those + any other media activities as far as I can tell. i.e. the demo page returns intents for "Select Music Track" and "Sound Recorder".
FWIW, the label on the <input> element is "Browse..." which is a bit confusing in the camera context.  Perhaps "Select Image" would be better in the accepts='image/*' case (although Chrome uses "Choose File" which is definitely worse!).
Attached patch Patch 1/2Splinter Review
We're always sending */* for the mimetype we want. Part of that is this incorrect if statement in nsIFilePicker.cpp I think. In nsHTMLInputElement we look over all the accepts and actually, when we fine image/* we DON'T add that mimetype. Instead we add a list of file extensions:

http://mxr.mozilla.org/mozilla-central/source/content/html/content/src/nsHTMLInputElement.cpp#4677

When we finish that loop, we also add an accepts */* filter too. So we end up with an mExtensionsFilter and mMimeTypeFilter both non empty.

This simple fix should fix that and force us to use ONE of the filters we have at least. We choose the extensions by default and then loop over them in java to build a mimetype. But for some reason the MimeTypeMap returns null for every extension:

http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoAppShell.java#1077

Which means we wind up with */* in the end anyway. I'm not sure what's up with MimeTypeMap. I'm gonna fix the nsHTMLInputElement bug instead in part 2 of this.
Attachment #666048 - Flags: review?(blassey.bugs)
Attached patch Patch 2/2Splinter Review
OK. Changed my mind. This fixes some checks in our nsIFilePicker implementation so that we correctly identify with we have the image filter set and can ignore the extensions bit.
Attached patch Patch 3/2Splinter Review
The list of file types being sent from Gecko actually has ; in it too, so this removes that. Note this still won't fix the bug because our file list contains some file extensions like 'ai' that return null and force us into accept-all mode.

Patch 2 actually fixes the bug by just sending the image/* mime type to Gecko.
Attachment #666104 - Attachment description: Patch → Patch 2/2
Attachment #666104 - Flags: review?(blassey.bugs)
Attachment #666105 - Flags: review?(blassey.bugs)
Attachment #666048 - Flags: review?(blassey.bugs) → review+
Attachment #666104 - Flags: review?(blassey.bugs) → review+
Attachment #666105 - Flags: review?(blassey.bugs) → review+
https://hg.mozilla.org/mozilla-central/rev/944020af0206
https://hg.mozilla.org/mozilla-central/rev/4442534ceff2
https://hg.mozilla.org/mozilla-central/rev/16bc4aa2f52f
Assignee: nobody → wjohnston
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18
You need to log in before you can comment on or make changes to this bug.