Bug 88298 – Support file extensions in HTMLInputElement::accept

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Kent Tamura]

Support file extensions in HTMLInputElement::accept

The WHATWG spec:
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#file-upload-state-(type=file)

> If specified, the attribute must consist of a set of comma-separated tokens, each of which must be an ASCII case-insensitive match for one of the following:
> The string audio/*
>   Indicates that sound files are accepted.
> The string video/*
>   Indicates that video files are accepted.
> The string image/*
>   Indicates that image files are accepted.
> A valid MIME type with no parameters
>   Indicates that files of the specified type are accepted.
> A string whose first character is a U+002E FULL STOP character (.)
>   Indicates that files with the specified file extension are accepted.

[Kent Tamura]

Created attachment 145708 [details]
Patch

is it possible to write a test for this?

[Kent Tamura]

(In reply to comment #2)
> is it possible to write a test for this?

We might be able to write a unit test for accept attribute parsing.  But it's impossible to test behavior of platform-dependent file chooser dialogs.

[Jon Lee]

Comment on attachment 145708 [details]
Patch

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

Unofficial r=me.

> Source/WebCore/ChangeLog:15
> +        FileChooserSettings::acceptMIMETypes in the future.

Is there a filed WK bug for this? If not, could you file it, and mentioned that bug here?

[Alexey Proskuryakov]

This is somewhat confusing. Don't we want to deal with one concept in DOM code, and have other type specifiers converted to that by platform code? in addition to MIME type and extension, there could be legacy Mac OS types/creators, OS level preferences, and who knows what else.

[Kent Tamura]

Yeah, handling of these types is platform-dependent. Some platforms use only MIME types, some platforms use only file extensions, and some platforms use both of MIME types and file extensions. 

The specification says:
> On platforms that only use file extensions to describe file types, the extensions listed here can be used to filter the allowed documents, while the MIME types can be used with the system's type registration table (mapping MIME types to extensions used by the system), if any, to determine any other extensions to allow. Similarly, on a system that does not have file names or extensions but labels documents with MIME types internally, the MIME types can be used to pick the allowed files, while the extensions can be used if the system has an extension registration table that maps known extensions to MIME types used by the system.

How about adding FileChooserSettings::acceptFileExtensions in addition to acceptMIMETypes?

[Alexey Proskuryakov]

I don't have much insight into where to do this, however it seems logical that a platform layer should map extensions to MIME types, and cross-platofrm code should deal with MIME types only. Do you foresee needing to specify extensions that don't have reasonable MIME type mappings?

OS X for instance doesn't use MIME types all that much - the internal concept of UTI is similar yet different.

[Kent Tamura]

(In reply to comment #7)
> I don't have much insight into where to do this, however it seems logical that a platform layer should map extensions to MIME types, and cross-platofrm code should deal with MIME types only. Do you foresee needing to specify extensions that don't have reasonable MIME type mappings?
> 
> OS X for instance doesn't use MIME types all that much - the internal concept of UTI is similar yet different.

Specifying file extensions in 'accept' HTML attribute is defined by the standard. We can't avoid file extensions in WebCore.

We might able to stop parsing accept attribute value at all. A platform layer parses it and recognizes file extensions and/or MIME types in this case. However this is not good for code sharing because accept attribute parsing is required by all of platforms.

[Kent Tamura]

Created attachment 145950 [details]
Patch 2

Keeping both of acceptMIMETypes and acceptFileExtensions

[Hajime Morrita]

Comment on attachment 145950 [details]
Patch 2

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

> Source/WebKit/chromium/src/ChromeClientImpl.cpp:729
> +    Vector<String> acceptTypes;

Is it possible to have FileChooserSettings::acceptTypes() ?

[Kent Tamura]

Created attachment 147723 [details]
Patch 3

FileChooserSettings::acceptTypes()

[WebKit Review Bot]

Comment on attachment 147723 [details]
Patch 3

Clearing flags on attachment: 147723

Committed r120410: <http://trac.webkit.org/changeset/120410>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

Apologies for bringing this up but so far I cannot get Safari to filter a file dialog by file extension; it permits any and all files to be selected for upload when I use ACCEPT=".stl" on an INPUT element.

Can someone review the code and test it again? We're having a number of Safari users uploading files which our backend isn't meant to accept.

[Alexey Proskuryakov]

Could you please file a new bug with a test case? Discussing the new problem here would be less effective and potentially confusing.