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

[Roland Steiner]

Hm, I guess I've been successfully convinced otherwise (i.e., "patch
upcoming!")... ^_^;

- Roland

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

>
> On Mar 23, 2010, at 1:40 AM, Roland Steiner wrote:
>
> 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...
>
>
> It doesn't start with "#". And I'm sure that if HTML5 meant "valid absolute
> URL" rather than "URL" it would say so.
>
> In any case, I think this aspect of the API is reverse-engineered from
> Mozilla, so if HTML5 and Mozilla do disagree, arguably it is HTML5 that's
> wrong and should be fixed. BUt in this case it doesn't look like it.
>
>
> 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/82f6e24c/attachment.html>