Miles in comment #50:
> Is my problem related or different? Using TB2.0.0.9, WinXP,SP2, cannot always
> drag an entry from the list of address books (and mailing lists) to another
> address book or mailing list. And this is still driving me buggy.
>
> Have discovered that if an entry does not contain an email address, it probably
> will not copy, although it may.
(In reply to comment #7)
> It looks like the ondragdrop(DropOnAddressListTree()) is never been called. I
> can't figure out why since it is working fine on NT. Need help from Drag&Drop
> team.
can someone determine if that still happens?
(In reply to comment #42)
> Since the modal dialog effectively prevents anyone from testing if the original
> bug still exists, I'll be adding a dependency.
as a result of the blocker, as a practical matter, I don't see much value to keeping this open, because prior to comment 27 there is no testcase, let alone a reduced testcase, and no clear steps that others can replicate. And no one from that era (except James I think) seems interested enough to speak up.
Unless we want this to be the cesspool for all drag and drop bugs with no testcases or poorly formed reports - in which case the currently vague summary needs improvement. But given this bug's ragged long history I'd sooner pick a newer, shorter, more clearly worded bug.
Miles in comment #50:
> Is my problem related or different? Using TB2.0.0.9, WinXP,SP2, cannot always
> drag an entry from the list of address books (and mailing lists) to another
> address book or mailing list. And this is still driving me buggy.
>
> Have discovered that if an entry does not contain an email address, it probably
> will not copy, although it may.
this issue is bug 248786
(In reply to comment #7) DropOnAddressLi stTree( )) is never been called. I
> It looks like the ondragdrop(
> can't figure out why since it is working fine on NT. Need help from Drag&Drop
> team.
can someone determine if that still happens?
(In reply to comment #42)
> Since the modal dialog effectively prevents anyone from testing if the original
> bug still exists, I'll be adding a dependency.
as a result of the blocker, as a practical matter, I don't see much value to keeping this open, because prior to comment 27 there is no testcase, let alone a reduced testcase, and no clear steps that others can replicate. And no one from that era (except James I think) seems interested enough to speak up.
Unless we want this to be the cesspool for all drag and drop bugs with no testcases or poorly formed reports - in which case the currently vague summary needs improvement. But given this bug's ragged long history I'd sooner pick a newer, shorter, more clearly worded bug.