Rather then have each of the WebKit clients parse the MIME types from the accept attribute string via FileChooser, WebCore should parse the string and pass a list. WebCore already has the HTML5 compatible parser logic. NOTE: Chromium is the only client that uses the "acceptType" attribute of FileChooser right now. They pass it along as a string and parse it later in chromium code. See also: <http://webkit.org/b/51045> [Qt] Implement HTML File Input "accept" attribute <http://webkit.org/b/45079> HTML <input type="file"> accept attribute
Created attachment 110082 [details] [PATCH] Proposed Fix I think this is the preferable approach. Rather then passing the "accept" attribute string to WebKit clients, we instead pass the parsed list of trimmed MIME types. This way ports don't have to write their own, possibly differing parsing implementations and we can make use of the HTML5 parsers already in WebCore. I'm not very familiar with WK2, but this looks like it would affect the WebKit2 API. Does that require any special considerations?
Comment on attachment 110082 [details] [PATCH] Proposed Fix Clearing flags. Based on some feedback I'm going to do some extra clean-up and break this up into parts.
Created attachment 110198 [details] [PATCH] Part 1 - Deprecate String version of acceptTypes Chromium folks, check out Part 3 when it is up. Instead of parsing the mime types in chromium WebKit ports should share the implementation in WebCore.
Created attachment 110199 [details] [PATCH] Part 2 - Switch a WebKit2 mirror struct to just use WebCore::FileChooserSettings
Created attachment 110200 [details] [PATCH] Part 3 - Add acceptMIMETypes parsed list to FileChooserSettings
Comment on attachment 110198 [details] [PATCH] Part 1 - Deprecate String version of acceptTypes Attachment 110198 [details] did not pass efl-ews (efl): Output: http://queues.webkit.org/results/10006296
(In reply to comment #6) > (From update of attachment 110198 [details]) > Attachment 110198 [details] did not pass efl-ews (efl): > Output: http://queues.webkit.org/results/10006296 Looks like the EFL port also used this and exposed it to their api as a char*: Eina_Bool (*run_open_panel)(Ewk_View_Smart_Data *sd, Evas_Object *frame, Eina_Bool allows_multiple_files, const char *accept_types, Eina_List **selected_filenames); If they want to move away from the deprecated type It looks like they could upgrade their API to use an Eina_List* for the MIME types list. I'll update Part 1.
Created attachment 110217 [details] [PATCH] Part 1 - Deprecate String version of acceptTypes (Fix EFL)
Comment on attachment 110217 [details] [PATCH] Part 1 - Deprecate String version of acceptTypes (Fix EFL) Attachment 110217 [details] did not pass gtk-ews (gtk): Output: http://queues.webkit.org/results/10006349
Part 1 and Part3 look reasonable. Please fix build failures of GTK and Windows.
Created attachment 110533 [details] [PATCH] Part 1 - Deprecate String version of acceptTypes (Fix Builds) I forgot to change the WebKit2 one that gets removed in the next patch. I retroactively created the patches. Lets give this one a shot on the bots, while my system is having a little bit of trouble building in general.
Comment on attachment 110533 [details] [PATCH] Part 1 - Deprecate String version of acceptTypes (Fix Builds) Looks good.
Comment on attachment 110200 [details] [PATCH] Part 3 - Add acceptMIMETypes parsed list to FileChooserSettings r=me
Landed the 3 Parts in: http://trac.webkit.org/changeset/97336 http://trac.webkit.org/changeset/97337 http://trac.webkit.org/changeset/97338
The bots look good. I think this is the first time I had 3 patches reviewed by 3 different people. Thanks for coming together! To remove the deprecated string I filed bugs on EFL and Chromium: <http://webkit.org/b/70002> [EFL]: Move from FileChooserSettings deprecatedAcceptType to acceptMIMETypes <http://webkit.org/b/70003> [Chromium]: Move from FileChooserSettings deprecatedAcceptType to acceptMIMETypes
*** Bug 45079 has been marked as a duplicate of this bug. ***