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

[Maciej Stachowiak]

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.html 
>>  line 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/df38e5a0/attachment.html>