57548 - [regression] filenames dragged into moz are unescaped (dnd spaces)

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect, P2)

Description

[Jesse Ruderman]

Steps to reproduce:
1. Drag "a b.txt" from your desktop into an open mozilla window
   result: nothing happens
2. Drag "a%20b.txt" from your desktop into an open mozilla window
   result: "a b.txt" loaded.

This may have regressed due to the patch for bug 52519, cc alecf.

Thanks to walk84 and zach in #mozillazine for helping me figure out what was 
happening.

Comment 1

[John Morrison]

Console messages on the drop:

****** DisplayErrCode 0x1
S_OK
S_OK
->>>>>>>>>>>>>> Write Clipboard to memory
->>>>>>>>>>>>>> Read Clipboard from memory
JavaScript strict warning:
chrome://navigator/content/navigatorDD.js line 379: reference to undefined 
  property aData.length

-> alecf, XPApps and nom. rtm -- dragging into the browser is broken.

Comment 2

[Peter Trudelle]

cc pinkerton

Comment 3

[Alec Flett]

ugh, this is totally my fault. I didn't even think to test dragging filenames 
with spaces. Duh!
I may just back out my change to bug 52519 since it just stopped working for 
some reason.

Comment 4

[Jesse Ruderman]

It would be nice if both bugs could be fixed correctly for rtm.  Before the fix 
for 52519, it was very hard to add bookmarklets such as the ones on 
www.google.com to the personal toolbar.

Comment 5

[don]

Marking "rtm need info".

Comment 6

[Alec Flett]

ok, I figured out what's going on - this is so horribly broken, I can't wait to 
fix this correctly on the trunk
it so happens that filenames dragged from the desktop ALREADY have their URLs 
escaped... I was unescaping data that I thought was only created from within 
mozilla. I have a fix, doing more testing now.

Comment 7

[Alec Flett]

ok, I'm reverting my change to retrieveURLfromData()... I thought it was 
necessary to fix the other bug, but I was wrong. pink, do you mind reviewing? 
this basically just puts retrieveURLfromData back the way it was, and it's only 
being used on the homebutton observer and the contentAreaDNDObserver. 

This will revert us back to the previous broken behavior that dragging a link 
into the content area, where the link itself contains spaces, won't work. I 
think it's more important that you can drag them into the bookmarks window.

Only the second half of the patch is relevant to THIS bug. The first half 
re-fixes bug 52519. I'll only check in that part for this bug.

Comment 8

[Alec Flett]

Attachment: patch that I forgot to checkin yesterday

Comment 9

[Alec Flett]

adding ben and law for sr=/r=

Comment 10

[Alec Flett]

ben sez "a=ben"

Comment 11

[don]

Bill, what's the good word?

Comment 12

[Bill Law]

I don't understand how we can remove that unescape() call.  It was part of a
much bigger fix for bug 52519 and I'm reluctant to just roll back just part of
that fix, without at least understanding the whole picture.

Don't we also have to undo some more of the original fix for 52519 (escaping or
put back the call to unescape elsewhere)?

Comment 13

[John Morrison]

Alec: just wondering about what the plan is for this bug. Not being able to 
drag "The Letter.html" into the browser from the desktop (win32/linux) is 
not good (and I would punt the bookmarklet fix in favour of getting normal
files to work again, if it comes down to a choice).

Comment 14

[Alec Flett]

ok, I backed out my other fix, fixing this one. I'll fix the other one in a
different way.