514831 - Missing newline in text/plain and text/uri-list causes ROX-Filer to reject DnD with error dialog

Status: UNCONFIRMED

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)

Description

[Luis Felipe]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-AR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-AR; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

When dragging links or file links from FF to ROX-Filer, it displays the message  "uri_list_to_glist: Incorrect or missing line break in text/uri-list data ", and "Sorry - I require a target type of text/uri-list or XdndDirectSave0. " when dragging a simple image. It's the same problem described in https://sourceforge.net/mailarchive/forum.php?thread_name=cd53a0140907050950g6feea1f9w12e6f3b4806db61e%40mail.gmail.com&forum_name=rox-devel
It had not happened with FF 2.*. Maybe the problem is related to the new implementation of the Drag and Drop API. Some other applications receive the link information and perform the correct action, but it's not the same in Scite and ROX.

Reproducible: Always

Steps to Reproduce:
1.Open Firefox and ROX-Filer in an empty folder, side to side if possible.
2.Navigate to any page containing links to files or with valid <img> tags
3.Drag the link to the file or the image to the ROX-Filer window.
Actual Results:  
If the Drag option is enabled (by default it is), the described error messages should appear.

Expected Results:  
If there's any download manager set int he Drag and Drop option, it should be launched. If not, an error message pointing at this option should appear.

Fixing this problem might help fix some other bugs like the Photoshop related Drag and Drop to open in Windows as well

Comment 1

[Mike Hommey [:glandium]]

While RFC 2169 says:
"As for all text/* formats, lines are terminated with a CR LF pair,
 although clients should be liberal in accepting lines with only 
 one of those characters."

RFC 2046 has this to say about text media types:
"The canonical form of any MIME "text" subtype MUST always represent a
 line break as a CRLF sequence.  Similarly, any occurrence of CRLF in
 MIME "text" MUST represent a line break.  Use of CR and LF outside of
 line break sequences is also forbidden."

It says nothing about line *termination*. It only talks about line *breaks*, and doesn't say anything I can see related to one-line texts required to end with a line break.

Comment 2

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.