Build ID: 2000052608 winme At mozilla.org, if you highlight plaintext and then mousedown on the scrollbar thumb and begin to drag up or down (as if to scroll), the native drag icon appears and the plaintext is apparently dragged into the body, which (as links do also - there's a bug about this) then attempts to go to the "url". However, since this is just plain text, this will usually cause a networking error (since there won't be a www.whatyouselected.com) Then, after dismissing the dialog, since the mousedown is never released from the scrollbars, you can move the scrollbars up and down without holding the mousebutton.

reassigning to puetzk@iastate.edu, who thinks he has some ideas about making this work. according to him, the problem likely likes in chrome/navigator/content/navigatorDD.js in the BeginDragContentArea function, where there's no check to see where the drag gesture actually was initiated

You may want to touch base with Kin Blas (kin@netscape.com) who has some work in progress for making D&D and Selection play well together.

*** Bug 40773 has been marked as a duplicate of this bug. ***

This also happens on Linux. It hasnt happened before 2000-052520.

yeah, kin is on bug 39821 which looks related. what we really need is some way to get the clipregion of the select and see if the event is within it kin, how connected is this to what you're doing? the real problem here is that there are lots of drag events that need to be kept away from this routine if it's going to just blindly assume that any drag it gets while there is a selection is a drag of the selection. It would seem better to have some way to ask if event.point is is the selection, so that you actually have to drag the selection to move it, not any random point on the page. Then most of these issues would go away.

As Kevin points out, this is a problem in BeginDragContentArea() in navigatorDD.js, which is a method that brade@netscape.com wrote. Assigning bug to brade@netscape.com. We may have to disable D&D support of selection until this gets resolved ... if this is blocking anyone, I can simply back out the change I checked into navigatorDD.js (rev 1.12) enable the feature to get you going again.

Don't know how I failed to see it last night, but nsIDOMSelection had all the plumbing to actually test if I node was part of the selection already in place, so this was really really simple. I shouldn't work on things so late :-)

OK, ben checked in the fix last night, and it seems to be fine. accepting and marking fixed, someone want to verify?

taking it...

and marking fixed

vrfy fixed