[webkit-dev] Leading new-line in dataTransfer.setData

[Roland Steiner]

Hm, but the first line could also be a comment (starting with '#') which
Mozilla also skips. IOW, I read the spec as "return the first line that is a
(valid) URL". But of course I could be convinced otherwise...

Cheers,

- Roland

On Tue, Mar 23, 2010 at 5:37 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Mar 23, 2010, at 1:01 AM, Roland Steiner wrote:
>
> Hi all,
>
> On the topic of dataTransfer.setData, there seems to be a small
> inconsistency between browsers when it comes to leading new-lines. e.g.,
> dataTransfer.setData("text/uri-list", "\nhttp://foo") followed by
> dataTransfer.getData("URL").
>
> Mozilla returns an empty string (see
> http://mxr.mozilla.org/mozilla1.9.2/source/content/events/test/test_dragstart.htmlline 271), while e.g., Chromium returns "
> http://foo".
>
> Now, the HTML5 spec says:
>
>     If the format (after conversion to lowercase) is "url", then the data
> associated with the "text/uri-list" format must be parsed as appropriate
> for text/uri-list data, and the first URL from the list must be returned.
> If there is no data with that format, or if there is but it has no URLs,
> then the method must return the empty string.
>
> Which I read that the Chromium result is correct (not surprisingly, since I
> wrote the code ;) ). However, inconsistency is never good, so what would you
> folks think about this (and what would be the correct Mozilla ML to raise
> this question)?
>
>
> text/uri-list is a newline-separated list, right? In which case the first
> URL in the list above is the empty string, and therefore Mozilla's behavior
> is right.
>
> Regards,
> Maciej
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20100323/0677c6e5/attachment.html>