User Agent: Mozilla/5.0 (Windows NT 6.1; rv:8.0a1) Gecko/20110720 Firefox/8.0a1 Build ID: 20110720030844 Steps to reproduce: I wanted to drag a link from Gtalk or Yahoo Messenger and drop it on Firefox. Actual results: Firefox can not accept this drop link and nothing happens. Expected results: Accepting drag and drop links from external application. This is supported on Chrome and IE.

Confirmed, with IE you can drop the link anywhere. With Chrome you can drop the link on the address bar or bookmarks bar. I like the feature of being able to place a link directly in the bookmarks bar or loading it by dragging it into the URL bar so I think I will go that route.

Oh, Also drag text (from an external application or a webpage inside firefox) and drop to search can be cool. Thank you

The drag text you can already do.

Oh, Yes, But I mean to tab bar for searching, Thanks again

Please file another bug for that one. It currently tries to load any text as a URL even if it is not a URI. Please CC me on it.

I moved the task for bookmarking non hyperlinked URLs via drag and drop into its own bug since it is not directly related to this task's Win32 widget code fix that is coming. It was moved here: Bug 673912 - Dragging non hyperlinked URLs on the bookmark bar should produce a bookmark

The problem was that we didn't handle any item that was being dragged which didn't support "move" and didn't support "copy", but did support "link".

Comment on attachment 548185 [details] [diff] [review] Fix for dragging link only elements onto any Win32 Widgets >+ else if(!mCanMove && !mCanCopy && mCanLink) { Nit: space between if and ( > mCanMove = (*pdwEffect) & DROPEFFECT_MOVE; Ooh, naughty, putting an int into a PRBool. None of our tools have spotted this because they only run on Linux and this is Windows-only code. It occurs to me that rather than storing three separate boolean values, you could simply store the drop effect in an int member and test its bits later. >+ if (pIDataSource) { >+ mCanLink = (S_OK == ::OleQueryLinkFromData(pIDataSource) ? PR_TRUE : PR_FALSE); I would only bother doing this if we don't already know we can link.

Thanks for the quick review, implemented the review comments.

Comment on attachment 548214 [details] [diff] [review] Fix for dragging link only elements onto any Win32 Widgets + review feedback > mMovePreferred = (preferredEffect & DROPEFFECT_MOVE) != 0; > } > else >- mMovePreferred = mCanMove; >+ mMovePreferred = (mEffect & DROPEFFECT_MOVE); Needs to be != 0 as above, since mMovePreferred is a boolean (unless you want to turn that into a WORD too...) r=me with that fixed.

Oops fixed, I'm used to bool/implicit conversions.

(In reply to comment #11) > I'm used to bool/implicit conversions. I don't think we go in for implicit bool conversions anyway; they generate compiler warnings in at least one of the compilers we use.

I suggest to keep using checkin-needed keyword to ask for checkin, a lot of developers are not yet tracking checkin? flag.

I may be wrong, but it seems to me that the commit message's grammar is completely broken...

It was the same as the subject of a bug, but I agree. Do you need me to submit a new patch with it fixed? How about: Bug 673080 - Dropping a link on Firefox from an external program has no effect.

Comment on attachment 548685 [details] [diff] [review] Fix for dragging link only elements onto any Win32 Widgets + review feedback Going to run through try before checkin flag

Sorry :)

ebraminio: No worries, thanks for posting!

Updated commit message

This was pushed to try, results in progress: http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=cde44aaad760

Pushed to mozilla-inbound: http://hg.mozilla.org/integration/mozilla-inbound/rev/89c47cdfad0a