When I open a new message compose window (Ctrl+M), focus starts in the body of the message and then is moved to the To field about a second later. Focus should start in the To field so I can start typing an address as soon as the window opens. Also, the code to focus the To field after the window opens should be removed, so that the focus doesn't jump back to the To field if I click on the body of the message right after opening the window.

marking nsbeta1+ and moving to mozilla0.8

See also bug 54788.

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

I have been looking at this for a while now and I think I know the problem. jag told me that the <editor/> control (which we use for the messagefield) automatically takes focus when created. When the WaitFinishLoadingDocument() function is called we call AdjustFocus() to set the focus at the appropriate place. So we first (automatically) call a function from the <editor/> constructor which sets itself to focus, then we call AdjustFocus() which most often sets the focus to the "To:" field in messagecomposewindow, that is the problem. What I think we should do is to implement some special command to the <editor/> which lets us pass the focus code without calling it. Does this make sense? Platform -> All OS -> All cc a bunch of people who might be helpful.

editor should not set automatically the focus when created.

Indeed it shouldn't. The problem is to find *where* in code Editor is focusing this field..?

moving to mozilla0.9

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

This problem probably has several reasons why it exists, I think I found one of them. In nsMsgCompose.cpp there are *lots* of calls everywhere to /editor->BeginningOfDocument();/, more than what is reasonable. The above function sets the cursor in the beginning of the document (the <editor/> widget) and thus this bug appears. I tried to disable all of the calls to BeginningOfDocument();, the editor didn't set the cursor in there as long as it used to but the cursor was still set there. I think a start to fix this bug is to cut down on /editor->BeginningOfDocument();/ spam, and then as we find new pieces of code which sets the cursor in the <editor/> field we eventually removes/cuts down on it. Ducarroz, in revision 1.163 of nsMsgCompose.cpp you added almost all these calls to BeginningOfDocument();. Any comments? http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/mailnews/compose/src&command=DIFF_FRAMESET&file=nsMsgCompose.cpp&rev2=1.163&rev1=1.162

Playing with the insertion point in the editor should not cause it to take the focus, if it does, it's a bug. By default, the first focusable element in the window should have the focus. I know that editor set the focus by itself but there is a test around it to no doing that when it in the message compose window. maybe this part of the code s broken. I am not looking at this bug right now because I am waiting on editor team to land the new editor which should be different in the way we initialze it and in particular in the way we load the about:blank document. This should append soon (maybe this week!)

>Playing with the insertion point in the editor should not cause it to take the >focus, if it does, it's a bug. If that's the problem here, I'm reminded of bug 41813.

reassign to varada

Involves changing code in xpfe/appshell/src/nsWebShellWindow.cpp. Re-assigning to hyatt.

My patch to 41813 covers this case.

Fixed.

OK using apr18 commercial trunk build : linux rh6.2, win98 and mac OS 9.0

Found while testing this fix: bug 76607, keys typed while message compose window loads freeze mozilla.

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

This has regressed: bug 143669.