Closed Bug 326641 Opened 18 years ago Closed 18 years ago

Clipboard paste command sometimes does nothing; may have to be pasting whole line.

Categories

(Thunderbird :: Message Compose Window, defect)

x86
Windows XP
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 299343

People

(Reporter: clydecrunchy, Assigned: mscott)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; en) Opera 8.51
Build Identifier: Thunderbird 1.5 (20051201)

"Paste without formatting" still works.

Reproducible: Sometimes

Steps to Reproduce:
1. Paste the plain text in Additional Information into a new mail compose window.
2. Copy or cut the entire line that says WaitForSingleObject(mutex,INFINITE) using the menu or ctrl-c or ctrl-x or ctrl-ins or shift-del.
3. Put the cursor at the beginning of the previous line.
4. Try to Paste using the menu or ctrl-v or shift-ins.

Actual Results:  
The paste does not take place.

Expected Results:  
Reliable pasting!  In this case the text made it onto the clipboard.  It would have been more serious if Cut deleted the text and just completely lost it.  But what if I had given up and retyped everything I couldn't paste?  If I thought my information was lost, then it might as well have been lost. Emails are sometimes really important and I have to be able to trust the clipboard!

"You have to be careful when using the wait functions and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses a wait function with no time-out interval, the system will deadlock. Two examples of code that indirectly creates windows are DDE and the CoInitialize function. Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than the other wait functions."

I think you should emphasize that Windows that waits forever for my thread, and that the deadlock is the result of outside activity rather than something my thread.

{
    CreateWindow("BUTTON","a",0,0,0,0,0,0,0,0,0);
    HANDLE mutex=CreateMutex(0,0,"APopularMutex");
    WaitForSingleObject(mutex,INFINITE);
}

This program is enough to cause a deadlock, if I understand correctly, because Windows could do a SendMessage while this program is stuck in the WaitForSingleObject.
This is working for me, TB 1.5 Win2K.

Do you have any extensions installed?  If so, do you see the same results after starting TB in Safe Mode?
Version: unspecified → 1.5
Fix is checked in to Core for Firefox 1.8.0.1, so it will (I believe) be part 
of TB 1.5.0.2, and should be in nightly builds now if you care to use those.
(I was using the 1.8-branch build from Jan 29 for several weeks with no particular problems.)

*** This bug has been marked as a duplicate of 299343 ***
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.