Dragging of IMAP message or folder is silently affected/canceled/interrupted by concurrent new message arrival notification/biff
Categories
(Thunderbird :: Folder and Message Lists, defect)
Tracking
(Not tracked)
People
(Reporter: bugzilla, Unassigned)
References
Details
(Keywords: reproducible, Whiteboard: [STR: comment 7, comment 14][analysis in bug 948082])
Attachments
(1 file)
67.37 KB,
image/png
|
Details |
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.
Updated•15 years ago
|
Comment 1•15 years ago
|
||
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)
Comment 2•15 years ago
|
||
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
Comment 3•15 years ago
|
||
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.
Comment 4•15 years ago
|
||
(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.
Comment 5•15 years ago
|
||
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
Comment 6•15 years ago
|
||
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.
Comment 7•15 years ago
|
||
str |
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.
Comment 8•15 years ago
|
||
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.
Comment 9•15 years ago
|
||
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.
Comment 10•15 years ago
|
||
I don't really see this on Mac as Mac uses Growl notifications.
Comment 11•15 years ago
|
||
Ok - seeing that on XP - but not on Mac OS.
Comment 12•15 years ago
|
||
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.
Comment 13•15 years ago
|
||
can someone test seamonkey linux?
Comment 14•15 years ago
|
||
str |
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.
Comment 16•15 years ago
|
||
(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.
Comment 17•15 years ago
|
||
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
Comment 18•15 years ago
|
||
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.
Comment 19•14 years ago
|
||
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
Comment 20•14 years ago
|
||
Timo, can you reproduce this?
Comment 21•14 years ago
|
||
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.
Comment 23•14 years ago
|
||
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
Comment 24•14 years ago
|
||
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?
Comment 25•13 years ago
|
||
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)
Comment 26•13 years ago
|
||
Sorry, I don't see how I can find time to put into any such testing in the near future.
Comment 28•12 years ago
|
||
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
Comment 29•12 years ago
|
||
Comment 30•12 years ago
|
||
No, this is nothing for me.
Comment 32•10 years ago
|
||
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?
Comment 33•10 years ago
|
||
(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."
Comment 34•10 years ago
|
||
(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.
Updated•10 years ago
|
Comment 35•10 years ago
|
||
wada has analysis in bug 948082. STM there's enough or close to enough information to discuss designing a patch
Updated•9 years ago
|
Updated•7 years ago
|
Updated•4 years ago
|
Comment 38•4 years ago
|
||
See comment 7 and comment 14. Can you reproduce and postulate a solution?
Comment 39•3 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #38)
See comment 7 and comment 14. Can you reproduce and postulate a solution?
Martin, can you reproduce?
Comment 40•3 years ago
|
||
Tested with the system notification on Windows 10 and Daily. The message isn't moved but the folder doesn't stay highlighted.
Comment 41•3 years ago
•
|
||
Super. Is it likely the fault can be caught by someone in the debugger? Or will it require someone with windows wizardry?
Comment 42•3 years ago
|
||
I can't say at all. Ping has some notifications knowledge . Maybe he can help.
Comment 43•3 years ago
|
||
(In reply to Wayne Mery (:wsmwk) from comment #38)
See comment 7 and comment 14 and bug 948082.
Ping, does anything come to mind that would lead to a solution, or how we could debug to get to the cause?
Updated•3 years ago
|
Updated•3 years ago
|
Comment 47•3 years ago
|
||
I think this is still blocked by bug 1001549 and bug 1197598, I have no idea how to fix it. A workaround is change to use the system alert.
Comment 49•3 years ago
|
||
Bug 1709047 seems to be quite different, see comment there.
Description
•