Open Bug 458570 Opened 16 years ago Updated 5 months ago

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)

x86
All
defect
Not set
major

Tracking

(Not tracked)

People

(Reporter: bugzilla, Unassigned)

References

Details

(Keywords: reproducible, Whiteboard: [STR: comment 7, comment 14][analysis in bug 948082])

Attachments

(1 file)

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.
Component: Mail Window Front End → Folder and Message Lists
QA Contact: front-end → folders-message-lists
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)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk
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
Summary: Popup "toast" messages while dragging a message over a folder causes erratic behaviour → imap message drag in progress affected/canceled by new message notification/biff
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.
Summary: imap message drag in progress affected/canceled by new message notification/biff → imap message or folder drag in progress affected/canceled by new message arrival notification/biff
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)
Blocks: 439333
(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
Keywords: helpwanted, qawanted
OS: Windows Vista → All
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.
Blocks: 273693
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?
Summary: imap message or folder drag in progress affected/canceled by new message arrival notification/biff → imap message or folder drag in progress silently affected/canceled by new message arrival notification/biff
Whiteboard: [Steps to reproduct: comment 7]
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)
Blocks: 490015
Whiteboard: [Steps to reproduct: comment 7] → [Steps to reproduce: comment 7]
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
Flags: needinfo?(james.brown)
Summary: imap message or folder drag in progress silently affected/canceled by new message arrival notification/biff → imap message or folder drag in progress is silently affected/canceled by new message arrival notification/biff
No, this is nothing for me.
Blocks: 841371
See Also: → 1019036
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."
Flags: needinfo?(james.brown) → needinfo?(m-wada)
Keywords: helpwanted, qawanted
Whiteboard: [Steps to reproduce: comment 7] → [STR: comment 7, comment 14]
(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.
Flags: needinfo?(m-wada)
Keywords: reproducible
Whiteboard: [STR: comment 7, comment 14] → [STR: comment 7, comment 14][analysis in bug 948082]
wada has analysis in bug 948082.
STM there's enough or close to enough information to discuss designing a patch
No longer depends on: 942610
See Also: → 942610
(it seems my sev=major 7 years ago didn't happen)
Severity: normal → major
See Also: → 1022443
Summary: imap message or folder drag in progress is silently affected/canceled by new message arrival notification/biff → imap message or folder drag in progress is silently affected/canceled/interrupted by new message arrival notification/biff
See Also: → 1442076
Blocks: 1442076
See Also: 1442076
Blocks: 1607094

See comment 7 and comment 14. Can you reproduce and postulate a solution?

Flags: needinfo?(geoff)

(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?

Flags: needinfo?(geoff) → needinfo?(richard.marti)

Tested with the system notification on Windows 10 and Daily. The message isn't moved but the folder doesn't stay highlighted.

Flags: needinfo?(richard.marti)

Super. Is it likely the fault can be caught by someone in the debugger? Or will it require someone with windows wizardry?

Flags: needinfo?(richard.marti)

I can't say at all. Ping has some notifications knowledge . Maybe he can help.

Flags: needinfo?(richard.marti)

(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?

Flags: needinfo?(remotenonsense)
Summary: imap message or folder drag in progress is silently affected/canceled/interrupted by new message arrival notification/biff → Dragging of IMAP message or folder is silently affected/canceled/interrupted by new message arrival notification/biff
Summary: Dragging of IMAP message or folder is silently affected/canceled/interrupted by new message arrival notification/biff → Dragging of IMAP message or folder is silently affected/canceled/interrupted by concurrent new message arrival notification/biff

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.

Flags: needinfo?(remotenonsense)

Bug 1709047 seems to be quite different, see comment there.

You need to log in before you can comment on or make changes to this bug.