795013 - accepts attribute not working correctly on input elements

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Wesley Johnston (:wesj)]

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

Comment 1

[cscott]

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!).

Comment 2

[Wesley Johnston (:wesj)]

Attachment: Patch 1/2

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.

Comment 3

[Wesley Johnston (:wesj)]

Attachment: Patch 2/2

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.

Comment 4

[Wesley Johnston (:wesj)]

Attachment: Patch 3/2

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.

Comment 5

[Wesley Johnston (:wesj)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/16bc4aa2f52f
http://hg.mozilla.org/integration/mozilla-inbound/rev/4442534ceff2
http://hg.mozilla.org/integration/mozilla-inbound/rev/944020af0206

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/944020af0206
https://hg.mozilla.org/mozilla-central/rev/4442534ceff2
https://hg.mozilla.org/mozilla-central/rev/16bc4aa2f52f