Bug 63063 - [EFL] Use accept attribute when executing the file picker for input element
Summary: [EFL] Use accept attribute when executing the file picker for input element
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit EFL (show other bugs)
Version: 528+ (Nightly build)
Hardware: Other Linux
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-21 06:01 PDT by Jongseok Yang
Modified: 2011-06-27 03:46 PDT (History)
5 users (show)

See Also:


Attachments
Use accept attribute for the file picker for INPUT element (5.91 KB, patch)
2011-06-21 06:29 PDT, Jongseok Yang
leandro: review-
Details | Formatted Diff | Diff
fix the naming scheme (5.92 KB, patch)
2011-06-21 19:51 PDT, Jongseok Yang
no flags Details | Formatted Diff | Diff
fix the naming scheme (5.92 KB, patch)
2011-06-24 01:03 PDT, Jongseok Yang
tkent: review-
Details | Formatted Diff | Diff
fix build error (5.96 KB, patch)
2011-06-26 23:39 PDT, Jongseok Yang
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jongseok Yang 2011-06-21 06:01:33 PDT
The accept attribute is only used with <input type="file"> and it specifies the types of files that can be submitted through a file upload.
EFL port should use the attribute within the function "ChromeClientEfl::runOpenPanel()"
Comment 1 Jongseok Yang 2011-06-21 06:29:22 PDT
Created attachment 97977 [details]
Use accept attribute for the file picker for INPUT element
Comment 2 Ryuan Choi 2011-06-21 07:05:24 PDT
Good point.
I didn't know that file type should control 'accept'.

Anyway.
Could you explain little bit about why we can remove suggestedFilenames.

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

> Source/WebKit/efl/WebCoreSupport/ChromeClientEfl.cpp:429
> +    CString accept = chooser->acceptTypes().utf8();
> +    confirm = ewk_view_run_open_panel(m_view, kit(frame), chooser->allowsMultipleFiles(), accept.data(), &selectedFilenames);

And as small thing, I think that it's no need to store it into accept.
Comment 3 Leandro Pereira 2011-06-21 14:56:24 PDT
Comment on attachment 97977 [details]
Use accept attribute for the file picker for INPUT element

Looks good; but please fix the naming scheme on the ewk_* files.
Comment 4 Gyuyoung Kim 2011-06-21 19:06:11 PDT
Comment on attachment 97977 [details]
Use accept attribute for the file picker for INPUT element

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

> Source/WebKit/efl/ewk/ewk_private.h:99
> +Eina_Bool ewk_view_run_open_panel(Evas_Object* o, Evas_Object* frame, Eina_Bool allows_multiple_files, const char* acceptTypes, Eina_List** selected_filenames);

For efl style, it is better to change acceptTypes with accept_types.
Comment 5 Jongseok Yang 2011-06-21 19:51:05 PDT
Created attachment 98105 [details]
fix the naming scheme
Comment 6 Jongseok Yang 2011-06-21 20:00:04 PDT
(In reply to comment #2)
> Good point.
> I didn't know that file type should control 'accept'.
> 
> Anyway.
> Could you explain little bit about why we can remove suggestedFilenames.
> 
> View in context: https://bugs.webkit.org/attachment.cgi?id=97977&action=review
> 
> > Source/WebKit/efl/WebCoreSupport/ChromeClientEfl.cpp:429
> > +    CString accept = chooser->acceptTypes().utf8();
> > +    confirm = ewk_view_run_open_panel(m_view, kit(frame), chooser->allowsMultipleFiles(), accept.data(), &selectedFilenames);
> 
> And as small thing, I think that it's no need to store it into accept.

I had thought that suggestedFilenames was not required.
I found out the below statement from HTML4 specification and I could not find out any comment about that from HTML5
"Creates a file select control. User agents may use the value of the value attribute as the initial file name."

I think that it's just implementation choice.
If you want to use the value, I will fix that.
Comment 7 Ryuan Choi 2011-06-21 20:06:01 PDT
(In reply to comment #6)
> (In reply to comment #2)
> > Good point.
> > I didn't know that file type should control 'accept'.
> > 
> > Anyway.
> > Could you explain little bit about why we can remove suggestedFilenames.
> > 
> > View in context: https://bugs.webkit.org/attachment.cgi?id=97977&action=review
> > 
> > > Source/WebKit/efl/WebCoreSupport/ChromeClientEfl.cpp:429
> > > +    CString accept = chooser->acceptTypes().utf8();
> > > +    confirm = ewk_view_run_open_panel(m_view, kit(frame), chooser->allowsMultipleFiles(), accept.data(), &selectedFilenames);
> > 
> > And as small thing, I think that it's no need to store it into accept.
> 
> I had thought that suggestedFilenames was not required.
> I found out the below statement from HTML4 specification and I could not find out any comment about that from HTML5
> "Creates a file select control. User agents may use the value of the value attribute as the initial file name."
> 
> I think that it's just implementation choice.
> If you want to use the value, I will fix that.

Thanks, I agree with you.
I couldn't find any way to give suggestedFilenames also.
Comment 8 Jongseok Yang 2011-06-24 01:03:48 PDT
Created attachment 98471 [details]
fix the naming scheme

fix the naming scheme from ewk_view.cpp
Comment 9 Kent Tamura 2011-06-24 03:37:58 PDT
Comment on attachment 98471 [details]
fix the naming scheme

r- because of EWS failures.
Comment 10 Jongseok Yang 2011-06-26 23:39:55 PDT
Created attachment 98666 [details]
fix build error

The cause for build error was that The FileChooser interface was changed by other-side.
I applied the new interface for FileChooser to my patch.
Comment 11 Gyuyoung Kim 2011-06-27 00:04:57 PDT
Comment on attachment 98666 [details]
fix build error

LGTM.
Comment 12 Kent Tamura 2011-06-27 03:02:31 PDT
Comment on attachment 98666 [details]
fix build error

Rubber-stamped by me
Comment 13 WebKit Review Bot 2011-06-27 03:46:08 PDT
Comment on attachment 98666 [details]
fix build error

Clearing flags on attachment: 98666

Committed r89812: <http://trac.webkit.org/changeset/89812>
Comment 14 WebKit Review Bot 2011-06-27 03:46:13 PDT
All reviewed patches have been landed.  Closing bug.