Bug 95698 – HTML file input elements do not support file extensions in the "accept" attribute

• Component: Forms
• Status: RESOLVED FIXED

[David Gatwood]

According to the current HTML spec:

    http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#attr-input-accept

The following is valid:

    <input type="file" accept=".myextension">

and should restrict the input to files with that extension.  Safari 6 does not seem to support this form of that attribute.  Please implement this functionality.

[Alexey Proskuryakov]

Could you please provide complete steps to reproduce? What specifically do you see that looks wrong - are you trying drag and drop, file chooser, or something else?

[David Gatwood]

Step 1: Put the element in an HTML file.
Step 2: Click on it.
Step 3: Look at the file chooser.  All files that do not match the above extension should be greyed out.  They are not.

Alternatively, include both an extension and one or more MIME types in the value, separated by commas.  Click on the "Choose File" button.  Notice that everything is greyed out except for files that match the MIME type(s), and you cannot choose anything that matches against the specified extension unless it also matches against one or more of the specified MIME types.

[Jon Lee]

Currently it looks like WK2 only looks at MIME types, and ignores extensions. Chrome looks at the aggregate.

[Radar WebKit Bug Importer]

<rdar://problem/12231850>

[Joseph Pecoraro]

Supporting extensions in <input type="file">'s accept attribute was a relatively recent addition to the HTML5 spec:
<http://html5.org/tools/web-apps-tracker?from=7056&to=7057>

It wasn't in the spec at the time that support was added to Safari. Neat, I didn't know about that.

[Blaze Burg]

Created attachment 316918 [details]
Patch

[Build Bot]

Attachment 316918 [details] did not pass style-queue:


ERROR: Source/WebKit/UIProcess/API/C/WKOpenPanelParametersRef.h:45:  The parameter name "parameters" adds no information, so it should be removed.  [readability/parameter_name] [5]
Total errors found: 1 in 9 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Darin Adler]

Comment on attachment 316918 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=316918&action=review

> Source/WebCore/ChangeLog:9
> +        Serialize the accepted file extensions so they can be accessed in UIPRrocess.

"UIPRrocess" -> "the UI process"

> Source/WebKit/ChangeLog:12
> +        Plumb accepted file extensions out to the C API. It is not
> +        added to the Cocoa API since the accepted MIME types are not
> +        available through that either. Better to add both together
> +        when they are actually needed.

Not sure that is the right thing for our future direction.

Instead I was hoping that we could make sure there was a way to bridge C API to Cocoa API so they can be mixed and then we would add this feature *only* to the Cocoa API.

> Source/WebCore/platform/FileChooser.h:99
> +    FileChooserClient* m_client = nullptr;

WebKit uses the " { nullptr }" syntax instead of the "= nullptr" syntax. Arbitrary, I know.

[Blaze Burg]

Comment on attachment 316918 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=316918&action=review

>> Source/WebKit/ChangeLog:12
>> +        when they are actually needed.
> 
> Not sure that is the right thing for our future direction.
> 
> Instead I was hoping that we could make sure there was a way to bridge C API to Cocoa API so they can be mixed and then we would add this feature *only* to the Cocoa API.

I'm not sure how to accomplish that. Have we tried it anywhere else?

I'm happy to change the Cocoa API in a separate patch to bring it up to parity. But it will require additional tests (API tests?) to make sure it's good for general consumption.

[Tim Horton]

(In reply to Brian Burg from comment #9)
> Comment on attachment 316918 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=316918&action=review
> 
> >> Source/WebKit/ChangeLog:12
> >> +        when they are actually needed.
> > 
> > Not sure that is the right thing for our future direction.
> > 
> > Instead I was hoping that we could make sure there was a way to bridge C API to Cocoa API so they can be mixed and then we would add this feature *only* to the Cocoa API.
> 
> I'm not sure how to accomplish that. Have we tried it anywhere else?

Most of the ObjC API objects are toll-free bridged with their C API counterparts.

> I'm happy to change the Cocoa API in a separate patch to bring it up to
> parity. But it will require additional tests (API tests?) to make sure it's
> good for general consumption.

[Blaze Burg]

Committed r220135: <http://trac.webkit.org/changeset/220135>

[Darin Adler]

(In reply to Brian Burg from comment #9)
> I'm not sure how to accomplish that. Have we tried it anywhere else?

Yes, I believe we have been taking that approach elsewhere.

> I'm happy to change the Cocoa API in a separate patch to bring it up to
> parity. But it will require additional tests (API tests?) to make sure it's
> good for general consumption.

I was not suggesting bringing it up to parity. I was suggesting putting new features *only* in Cocoa API and not adding to the C API.