[Please do not change the summary. Symptoms match numerous cut and paste bugs in Gecko 1.8.x/FF 1.5, but this bug is filed as a regression against trunk] XP-PRO. Trunk fails starting version 3 alpha 1 (20060511), works on 20060510. Regression range 2006-05-10 09:00:00 - 2006-05-11 07:30:00 includes Bug 336957 and the landing of bug 326273 "Implement nsIThreadManager", perhaps a prime suspect. Thunderbird 1.5 works great, 1.5.0.4 in this case, in this specific setup. Steps to Reproduce: (nicely described in bug 343507) 1. Thunderbird is set as default e-mail client on your system 2. Browse to a web page using Firefox 3. Click on File | Send link or right-click in page and "send link" 4. message compose window opens 5. go back to web page in Firefox 6. Click on File | Send link... 7. message compose window opens Expected results: able to paste in "To:" and body, and able type in To: field Symptoms/Actual results: * unable to paste in To: field and body of second and all subsequent compose windows (but the first window is OK) * all edit menu commands are greyed out (unavailable), except "select all" * no keyboard navigation (arrows, etc) in message body (but able to type) * no cut and paste via keyboard or context menu of selected text in message body Compose window is "fixed" (mostly) by saving the message as draft, opening error console and doing anything to focus away from the compose window - alt tab and back. Reproducible: 99%

I'm able to reproduce this as well. I could have sworn we've had this problem before (another symptom: you get two carets, one in the subject field and one in the message body). If someone can find the bug and what fixed it the last time this happened, that would be a big help. It may have been related to the split window changes at the time. I wonder if this was introduced when Bug 353906 landed...

the problem also appears to be limited to re-opening cached compose windows.

I'm not able to reproduce this, at least with a debug build.

(In reply to comment #3) > I'm not able to reproduce this, at least with a debug build. > David, does it work for you if Thunderbird is already running, you've already opened and closed a compose window so the send link command is opening a cached window? When I do that, I can type in the message body box but the editor toolbar controls never become enabled. Win32, trunk. My trunk release build is from last week though. I'll update and test again.

yes, everything is fine. The edit toolbar is disabled when I'm in the address widget, but when I tab to the message body, it's fine. This is from a debug build that I pulled and built Saturday, iirc.

This may be an edge case of the focus or some other issue, the fact that others can't reproduce this doesn't surprise me. But it's nice that you see it Scott :) I look forward to seeing how Oliver's patch in bug 220900 affect this testcase. As for cached window, I had tested with it off (0) and IIRC TB wouldn't even open a compose window (think I mentioned in passing to bienvenu a few days ago). Pretty nasty.

(In reply to comment #1) > I'm able to reproduce this as well. I could have sworn we've had this problem > before (another symptom: you get two carets, one in the subject field and one > in the message body). If someone can find the bug and what fixed it the last > time this happened, that would be a big help. It may have been related to the > split window changes at the time. Yup. I also looked in this area. two carets is bug 303976. It states "pasting doesn't work in the compose window either until focus is moved away and then back into the compose window." See also bug 303976 comment 7. 303976 declared "fixed" on 8/17, no bug #, regression blockers or patch, but according to comments was due to split window. However, can't be fixed due to bug 303976 - had no patches as of 8/17 - so perhaps fixed by patches from bug 296639? worth mentioning, several currently open cut & paste bugs claim windows started with split windows (bug 296639). The regression cut and paste bug 305032 was marked fixed, but it has no open regressions marked (as blockers). To jog memory cells and not sure this is relevant, but I'll also cite bug 305032 comment 91 "was MsgComposeCommands.js .. ever checked in on the branch when https://bugzilla.mozilla.org/attachment.cgi?id=195055 was checked into the branch on 09/07. That's causing Bug 308822." > I wonder if this was introduced when Bug 353906 landed... My problem is several months older to least May 11 and 353906 is recent - is 353906 the number you wanted?

(In reply to comment #7) >.. > 303976 declared "fixed" on 8/17, no bug #, regression blockers or patch, but > according to comments was due to split window. However, can't be fixed due to > bug 303976 - had no patches as of 8/17 - so perhaps fixed by patches from bug > 296639? correction - can't be fixed due to bug 305032 (not 303976)

(In reply to comment #6) > As for cached window, I had tested with it off (0) and IIRC TB wouldn't even > open a compose window (think I mentioned in passing to bienvenu a few days > ago). Hmm, ATM I can't seem to recreate with mail.compose.max_recycled_windows=0 on a clean or default profile. But, as before, it did not alleviate my problem. I want to emphasize 99% reproducible - if I do several "send links" in a row it will sometimes open a compose window that I CAN paste into.

*** Bug 356063 has been marked as a duplicate of this bug. ***

patch for bug 220900 appears to fix this problem on XP and 2000, though I have further tests to do. It would be great to get that patch on the trunk, as it probably fixes numerous focus issues. How does the patch tie/relate to my regression window of 5-10-2006?

I've just encountered an odd variation on this symptom -- maybe the same problem, maybe not. I use 'Send Link in Mail' from Opera. Normally, I'm running in plain text; and with a trunk TB (3a1-1031), I see the symptoms in this bug. I had switched to a default of HTML for testing, then I tried a Send Link without switching back. There was no text in the message body, which is bad; I see this reproducibly in trunk and branch -- a different bug? I'm also seeing -- trunk and branch, plain and HTML -- that a cached compose window opened with Send Link, then closed without sending, puts up the following in the in JS Console: Error: sMsgComposeService is not defined Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js Line: 1063 If the window isn't cached, or if it was opened with Write, Reply, Forward, that error doesn't appear. Finally, in 2b1-1111, Send Link into an HTML window, I also noticed that when I clicked in the Subject, the arrow/home/end keys weren't working there. This isn't completely reproducible; I saw it happen again, but I can't make it happen now. I haven't seen this symptom with 3a1, but since I don't have Steps to Reproduce, I can't say it won't ever show up there.

my problem is fixed 100% by patch to bug 220900 Mike in comment #12: > I've just encountered an odd variation on this symptom -- maybe the same > problem, maybe not. > > I use 'Send Link in Mail' from Opera. Normally, I'm running in plain text; and > with a trunk TB (3a1-1031), I see the symptoms in this bug. > > I had switched to a default of HTML for testing, then I tried a Send Link > without switching back. There was no text in the message body, which is bad; I > see this reproducibly in trunk and branch -- a different bug? Mike, still see this? > I'm also seeing -- trunk and branch, plain and HTML -- that a cached compose > window opened with Send Link, then closed without sending, puts up the > following in the in JS Console: > Error: sMsgComposeService is not defined > Source File: chrome://messenger/content/messengercompose/MsgComposeCommands.js > Line: 1063 > If the window isn't cached, or if it was opened with Write, Reply, Forward, > that error doesn't appear. I see this also (but didn't try uncached) > Finally, in 2b1-1111, Send Link into an HTML window, I also noticed that when I > clicked in the Subject, the arrow/home/end keys weren't working there. This > isn't completely reproducible; I saw it happen again, but I can't make it > happen now. I haven't seen this symptom with 3a1, but since I don't have Steps > to Reproduce, I can't say it won't ever show up there. still see this?

(In reply to comment #14) > my problem is fixed 100% by patch to bug 220900 Interesting that that fix was required on both branch and trunk when this bug was trunk-only -- but yeah, I don't see the original problem. I think when I posted comment 12, I didn't even bother to test the original problem -- my bad. Fine with me to mark this Fixed. > Mike in comment #12: > > I had switched to a default of HTML for testing, then I tried a Send Link > > without switching back. There was no text in the message body, which is > > bad; I see this reproducibly in trunk and branch -- a different bug? > > Mike, still see this? I do; I also see it in 1.5. Plain text compose works fine from Opera, both types of compose work fine from Firefox. I've opened bug 366247 for this. > > Finally, in 2b1-1111, Send Link into an HTML window, I also noticed that > > when I clicked in the Subject, the arrow/home/end keys weren't working > > there. This isn't completely reproducible; I saw it happen again, but I > > can't make it happen now. I haven't seen this symptom with 3a1, but since > > I don't have Steps to Reproduce, I can't say it won't ever show up there. > > still see this? No, but as I said, no reliable STR.