User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.3) Gecko/2008092417 Firefox/3.0.3 Build Identifier: version 2.0.0.17 (20080914) If you receive new mail while dragging and about to drop a message into a folder, the drag-and-drop operation is cancelled and the folder that you were hovering over gets stuck highlighted blue. Reproducible: Didn't try Steps to Reproduce: 1. Mouse down over a message 2. Hover over a folder in the Folders pane as though about to drop the message there 3. Receive a new mail (this is the hard part to reproduce!) 4. Wait for the toast to disappear (maybe) 5. Try to drop your message into a different folder. Actual Results: Not only does the message not move at all, but the first folder that you hovered over remains highlighted from when you were "about" to drop into it. Expected Results: The first folder should lose its highlight and the message should be dropped into the final destination folder.

confirming. Will and I worked on IRC and we can easily recreate this with biff ("show an alert") checked on. We also tried with alert off but sound on, and could not reproduce. Reproducible: always The next thoughts are: a) Does this also happen when dragging a folder rather than a message? And, can it happen *after* dropping a folder, while the copies are in progress? (some bugs mentioned in bug 489757) b) Does this happen with biff/alert off? (I see this, irregularly, on 2 systems where biff is not on)

Bienvenu, do we need a stack trace for this? Only imap drag is affected, if my testing is correct. Drag from local folder did not fail. I tested drag from pop once. Also, I saw the effect in comment 0, "folder that you hovered over remains highlighted" (and message doesn't drop) when I dragged to a different imap account. I didn't test the thoughts in comment 1. xref bug 490015 refusing to start any more drags after a drop failure

I'm not sure how you'd get a stack trace. Is either the source or the destination of the drag the Inbox? If not, it sounds a bit like a focus issue where if the widget that has drop focus loses focus, the drag drop code gets very confused. Maybe you could test this with something like alt tab.

(In reply to comment #3) > I'm not sure how you'd get a stack trace. true > Is either the source or the destination of the drag the Inbox? no, folder doesn't matter > If not, it > sounds a bit like a focus issue where if the widget that has drop focus loses > focus, the drag drop code gets very confused. Maybe you could test this with > something like alt tab. alt-tab has no effect on the drag status.

forgot to mention, if testing is correct, biff doesn't fire when drag in progress from local folder - which would account for local drag not being affected

I had this happen in the case that the biff icon showed up, but the alert window didn't raise... It still feels like a widget thing to me - the folder tree never seems to figure out that I've let go of the mouse button, and leaves just the folder name highlit forever.

David, see side effects I mention in bug 489757 comment 8. And thanks for testing this. just tested folders - folder drag is also affected. but not local folders. drag of selected text - also *not* affected. conclusion, problem seems tightly related to imap. 100% reproduction via these steps ... 1. enable "Show an alert" for new message arrival in options 2. set any imap account A to 1 minute refresh (only so things happen faster) 3. start a drag message operation from any imap account B 4. hold mouse button down, placed anywhere on the screen (doesn't matter where) 5. send a message to account A 5. wait for notification of new message Results: NO visual change in the drag widget, and message can't be dropped Account of message being dragged can be different from account of the newly arrived message (or same). My experience detailed in bug 489757 indicates alert box is not a necessary item, but seems to make problem more reproducible.

gnarly - I dragged 101 messages from an imap folder to a local folder - which at some point was interrupted by a new message (which was filtered from inbox to another imap folder). visually, it appeared the drop worked. But, abnormally, the messages were still selected in the source folder and not deleted. activity manager (to the best of my recall) did not record the move to local. after a long delay (30 seconds?), AM logged the deletes and messages disappeared from target folder. The gnarly part is, I couldn't display the target folder - no access to the msf. I could display the messages with message search (perhaps quick search would have also worked). Fearing the worst, I restarted TB and on first access of the target folder TB rebuilt the index and folder displayed. I copied the "bad" index file in case it is worth anything. so this would appear to be one way to blow a folder, drag and drop and be interrupted by an incoming message.

Still needing help to see if steps of comment 7 reproduce on linux. And a second test on Mac. sev>major because this sometimes leads to one of the following: 1. drag and drop totally stops working, sometimes for a few minutes, sometimes forever - this requiring restart (sort of like 490015) 2. if drag and drop does work, I often see evidence of corrupted indexes (**) which require rebuilding index (bug 439333) copying from bug 489757... * query for finding related bugs: http://tinyurl.com/rygucq (ignore bug 471128. and doubt bug 249445 is related) * bug 489757 comment 3 Jay could not reproduce on: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090422 Shredder/3.0b3pre Running on an Intel Mac Book Pro 2.6Ghz, Mac OSX 10.5.6, Wireless Mighty Mouse.

I don't really see this on Mac as Mac uses Growl notifications.

Ok - seeing that on XP - but not on Mac OS.

fails with seamonkey 2.0 pre 20090529 under XP. 20090116 also where I see what Will describes "folder that you hovered over remains highlighted from when you were "about" to drop" But doesn't fail 100%. perhaps depends whether notification pops up (stops appearing after first failure?) - i didnt' test enough to determine.

can someone test seamonkey linux?

On Vista, I plugged in an external usb hard drive and then started dragging a thunderbird window around - when vista noticed the usb hard drive, it popped up a window and cancelled my drag drop. So this might be fairly specific to the windows dock.

still able to reproduce with 20090824 (tested XP)

(In reply to comment #9) > Still needing help to see if steps of comment 7 reproduce on linux. Confirming that it occurs in Linux version of Tb ( Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090825 Shredder/3.0b4pre ) by following the same steps as suggested at step 7.

smichaud, having looked at bug 449951 comment 2, is this widget issue of interest to you? We still don't quite understand the interaction happening with the drag. If bug 38646 is valid, I wonder if it isn't a factor here. Nir, thanks for the test

This happens on Windows, OS X and Linux. So I don't think it can be a widgets bug (since all widgets code is platform-specific). It's certainly not a *Cocoa* widgets bug.

Difficult to get a good query for this. I don't claim this is good ... rough query of drag bugs (not all related to this bug) https://bugzilla.mozilla.org/buglist.cgi?value1-1-0=455248%20533766;type1-0-0=nowordssubstr;type0-1-0=nowordssubstr;field0-1-0=component;short_desc=drag;field0-0-0=short_desc;bug_severity=major;bug_severity=normal;resolution=---;type1-1-0=nowordssubstr;query_format=advanced;value0-1-0=imag%20%20address%20compos%20attach%20eml%20rss%20feed%20icon;field1-1-0=bug_id;value1-0-0=closeme;short_desc_type=allwordssubstr;type0-0-0=nowordssubstr;value0-0-0=imag%20address%20compos%20attach%20eml%20rss%20feed%20icon%20header%20;field1-0-0=status_whiteboard;product=MailNews%20Core;product=Thunderbird no bugs were found key on anything to do with new/incoming + "drag" in comment

Timo, can you reproduce this?

I don't know why you're asking me, but I anyway couldn't reproduce with Debian's icedove v2.0.0.22-1.1.

I can reproduce this on Fedora 13. Didn't really see any information in particular that we needed for further troubleshooting. Let me know what I can gather to help in resolving this. Thanks! thunderbird-3.0.5-1.fc13.x86_64

James in comment #23 > I can reproduce this on Fedora 13. Didn't really see any information in > particular that we needed for further troubleshooting. Let me know what I can > gather to help in resolving this. Thanks! > > thunderbird-3.0.5-1.fc13.x86_64 james, (or anyone) can you get a short stacktrace of the failure?

kairo, does this reproduce on linux using comment 7? I can still easily reproduce with current trunk with windows. (only tried once, and didn't see bug 490015)

Sorry, I don't see how I can find time to put into any such testing in the near future.

aceman, can you determine the point of failure? james, can you still reproduce on linux? STR are still good. Some behavior seems to be better (The target folder doesn't seem to get permanently locked - bug 490015), but some aspects of comment 7 still occur. I tested dragging only one selected message: 1. if mouse is not over a target folder (no drop zone) when notification pops, then selection+drag is lost. however, I can go back and do it again 2. if mouse is over a target folder the folder name is blanked out, and when notification pops the selection+drag is lost and folder name is stays blanked out (for example scroll the folder list) ... unless a) you click on the target folder, or b) successfully drag a message to it

No, this is nothing for me.

It looks that bug opener of bug 948082 can reproduce problem with "Drag&Drop of message/folder which is irrelevant to IMAP" and "notification in IMAP". Drag of imap message or folder actually needed?

(In reply to WADA from comment #32) > It looks that bug opener of bug 948082 can reproduce problem with "Drag&Drop > of message/folder which is irrelevant to IMAP" and "notification in IMAP". Perhaps we should dupe that bug to this and avoid the fragmentation. Note also, the tool you cite there is no longer available http://www.h2.dion.ne.jp/~radon/mozilla/tb-addon/WinBackMyTrash-1-Button.js.txt > Drag of imap message or folder actually needed? perhaps not, but it is certainly the most common situation. Are you able to reproduce in non-imap situation? note, James in comment 23 no longer uses Thunderbird and "can't help with further testing/validation."

(In reply to Wayne Mery (:wsmwk) from comment #33) > Are you able to reproduce in non-imap situation? No, I don't know how to reproduce problem without "imap notification", while dragging something from somewhere to elsewhere. Bug opener of bug 948082 always utilized "imap notification" for reproducing problem. And, I don't know how to consistently produce "imap notification" while doing drag, although bug opener of bug 948082 could produce it repeatedly.

wada has analysis in bug 948082. STM there's enough or close to enough information to discuss designing a patch

(it seems my sev=major 7 years ago didn't happen)