You need to
before you can comment on or make changes to this bug.
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.
<http://webkit.org/b/51045> [Qt] Implement HTML File Input "accept" attribute
<http://webkit.org/b/45079> HTML <input type="file"> accept attribute
Created an attachment (id=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?
(From update of attachment 110082 [details])
Clearing flags. Based on some feedback I'm going to do some extra clean-up and break this up into parts.
Created an attachment (id=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 an attachment (id=110199) [details]
[PATCH] Part 2 - Switch a WebKit2 mirror struct to just use WebCore::FileChooserSettings
Created an attachment (id=110200) [details]
[PATCH] Part 3 - Add acceptMIMETypes parsed list to FileChooserSettings
(From update of attachment 110198 [details])
Attachment 110198 [details] did not pass efl-ews (efl):
(In reply to comment #6)
> (From update of attachment 110198 [details] [details])
> Attachment 110198 [details] [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 an attachment (id=110217) [details]
[PATCH] Part 1 - Deprecate String version of acceptTypes (Fix EFL)
(From update of attachment 110217 [details])
Attachment 110217 [details] did not pass gtk-ews (gtk):
Part 1 and Part3 look reasonable. Please fix build failures of GTK and Windows.
Created an attachment (id=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.
(From update of attachment 110533 [details])
(From update of attachment 110200 [details])
Landed the 3 Parts in:
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. ***