61137 - Error in contentAreaDD.js: url.indexOf is not a function

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect, P2)

Description

[km]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS 5.8 sun4u; en-US; m18) Gecko/20001123
BuildID:    2000112321

Drag and Drop of bookmark to main window fails
in all cases.

Reproducible: Always
Steps to Reproduce:
Drag and Drop any bookmark in main window

Actual Results:  Got error message

 http://browserwatch.iworld.com/whatsnew-table-current.html    Parent ID:
NC:BookmarksRoot#$cd0f503e    Type:
'http://home.netscape.com/NC-rdf#Bookmark'genData is
http://browserwatch.iworld.com/whatsnew-table-current.html
NC:BookmarksRoot#$cd0f503e len is 85
TOP LEVEL bookmarks window got a dragJavaScript error:
chrome://communicator/content/contentAreaDD.js line 158: url.indexOf is not a
function

Does not go to bookmark url

Expected Results:  Should have accepted drag and drop url and
gone to it.

The drag and drop has recently (since M18) been
changed. Its now handled by a javascript
contentAreaDD.js. One line 158 this code
attempts to make sure there is no embedded
space in the URL. It uses url.indexOf to
check for the space.

url.indexOf is not defined so the check fails
in all cases.

There are also other uses of url.indexOf
which presumably will also fail.

I doubt this is Sun/Solaris specific and probably at least a generic
Unix problem.

Comment 1

[Peter "jag" Annema]

indexOf is actually defined on strings, and that's what url should be there.
Apparantly, it's not.

I currently see one problem with that code:
|retrieveURLFromData(data)| could return a |null| but the next line doesn't
check for that. It should be something like |if (!url || url.length == 0)|

I'll see if I can find out what's going on here. For some reason, a text/unicode
object (not string!) is dropped.

Comment 2

[Peter "jag" Annema]

reassigning to alecf, cc'ing blake.

Comment 3

[Alec Flett]

argh! this is yet another slight variation in flavor stuff. Accepting.
we can fix this by manually calling toString() if necessary.

Comment 4

[Peter "jag" Annema]

Shouldn't "text/unicode" hint that it is a string? And iirc, strings in JS are
unicode. In this case, yes, .toString() will work, but I'd rather we fix this
the right way.

Comment 5

[Peter "jag" Annema]

Hmmm...

Apparantly this is about the difference between DOMStrings and wstrings. The
strings here are wstrings and not DOMStrings. Take a look at readFromClipboard()
in navigator.js to see one solution.

I guess .toString() works just as well, so just ignore my previous comment :-)

Comment 6

[Alec Flett]

well, it's more like an nsISupportsWString != a string... but I'll address that
in my patch :)

Comment 7

[Alec Flett]

Attachment: fix - explicitly convert to a String object

Comment 8

[Blake Ross]

r=blake

Comment 9

[Ben Goodger (use ben at mozilla dot org for email)]

a=[e-mail]

Comment 10

[Alec Flett]

fix is in.

Comment 11

[sairuh (rarely reading bugmail)]

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]