Bug 76925 - dropzone does not normalize type strings
Summary: dropzone does not normalize type strings
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Daniel Cheng
URL:
Keywords:
Depends on:
Blocks: 76218 76598
  Show dependency treegraph
 
Reported: 2012-01-24 10:40 PST by Daniel Cheng
Modified: 2012-01-24 13:54 PST (History)
2 users (show)

See Also:


Attachments
Patch (3.00 KB, patch)
2012-01-24 11:16 PST, Daniel Cheng
no flags Details | Formatted Diff | Diff
Patch (3.01 KB, patch)
2012-01-24 12:44 PST, Daniel Cheng
no flags Details | Formatted Diff | Diff
Patch (2.86 KB, patch)
2012-01-24 13:20 PST, Daniel Cheng
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Cheng 2012-01-24 10:40:41 PST
Per http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#the-dropzone-attribute, the types are supposed to be normalized by lowercasing (with NO special conversion from text->text/plain and url->text/uri-list, but since dropzone checks against the types() collection directly, the type normalization that ports generally do in getData()/setData(), etc is ignored.
Comment 1 Daniel Cheng 2012-01-24 11:16:26 PST
Created attachment 123775 [details]
Patch
Comment 2 Tony Chang 2012-01-24 11:47:44 PST
Comment on attachment 123775 [details]
Patch

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

> Source/WebCore/ChangeLog:11
> +        Covered by existing tests.

I would say that you changed/added a test case in fast/events/dropzone-002.html.

> LayoutTests/ChangeLog:10
> +        * fast/events/dropzone-002.html: Update layout test to check case normalization as well.
> +        Also fixes the test to use text/uri-list, since no URL->text/uri-list special casing is
> +        defined for new drag and drop APIs.

Does no special casing of URL->text/uri-list defined mean that string:url should fail?  It seems bad to lose test coverage for that case: we should test both string:url and string:text/uri-list.
Comment 3 Daniel Cheng 2012-01-24 12:44:59 PST
Created attachment 123785 [details]
Patch
Comment 4 Daniel Cheng 2012-01-24 12:52:19 PST
Comment on attachment 123775 [details]
Patch

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

>> Source/WebCore/ChangeLog:11
>> +        Covered by existing tests.
> 
> I would say that you changed/added a test case in fast/events/dropzone-002.html.

Done.

>> LayoutTests/ChangeLog:10
>> +        defined for new drag and drop APIs.
> 
> Does no special casing of URL->text/uri-list defined mean that string:url should fail?  It seems bad to lose test coverage for that case: we should test both string:url and string:text/uri-list.

I'm not sure how I should check this. I could add a new dropzone test and set the expectation that no drop should happen? I looked around the existing dropzone tests and it doesn't seem like there's a 'negative' dropzone test that checks for things that shouldn't match. Perhaps I could add one in a separate patch, as that's not directly related to fixing the normalization of type strings.
Comment 5 Tony Chang 2012-01-24 12:56:17 PST
(In reply to comment #4)
> > Does no special casing of URL->text/uri-list defined mean that string:url should fail?  It seems bad to lose test coverage for that case: we should test both string:url and string:text/uri-list.
> 
> I'm not sure how I should check this. I could add a new dropzone test and set the expectation that no drop should happen? I looked around the existing dropzone tests and it doesn't seem like there's a 'negative' dropzone test that checks for things that shouldn't match. Perhaps I could add one in a separate patch, as that's not directly related to fixing the normalization of type strings.

I actually think it's OK for URL->text/uri-list to happen, although we should ask for the spec to be clear about this.

My main point was that we should not remove the test case that covers this behavior regardless of what the result is.  Layout tests are primarily for regression coverage.
Comment 6 Daniel Cheng 2012-01-24 13:20:11 PST
Created attachment 123790 [details]
Patch
Comment 7 Daniel Cheng 2012-01-24 13:32:50 PST
Comment on attachment 123790 [details]
Patch

Clearing flags on attachment: 123790

Committed r105800: <http://trac.webkit.org/changeset/105800>
Comment 8 Daniel Cheng 2012-01-24 13:32:54 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Yael 2012-01-24 13:50:41 PST
Comment on attachment 123790 [details]
Patch

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

> Source/WebCore/dom/Clipboard.cpp:217
> -        return hasFileOfType(keyword.substring(5));
> -                             
> +        return hasFileOfType(keyword.substring(5).lower());
> +
>      if (keyword.startsWith("string:"))
> -        return hasStringOfType(keyword.substring(7));
> +        return hasStringOfType(keyword.substring(7).lower());

The dropZone attribute is converted to lowercase in findDropZone(), before this is called.
Why was this change needed?
Comment 10 Daniel Cheng 2012-01-24 13:54:06 PST
(In reply to comment #9)
> (From update of attachment 123790 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=123790&action=review
> 
> > Source/WebCore/dom/Clipboard.cpp:217
> > -        return hasFileOfType(keyword.substring(5));
> > -                             
> > +        return hasFileOfType(keyword.substring(5).lower());
> > +
> >      if (keyword.startsWith("string:"))
> > -        return hasStringOfType(keyword.substring(7));
> > +        return hasStringOfType(keyword.substring(7).lower());
> 
> The dropZone attribute is converted to lowercase in findDropZone(), before this is called.
> Why was this change needed?

The original intent was to address url->text/uri-list normalization as well but that's been deferred to a separate patch.

The layout test change is still valuable; I should revert the code change though. Sorry about missing that.