62452 - message compose window should have To field focused as soon as it opens

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P2)

Description

[Jesse Ruderman]

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.

Comment 1

[scottputterman]

marking nsbeta1+ and moving to mozilla0.8

Comment 2

[Jesse Ruderman]

See also bug 54788.

Comment 3

[Håkan Waara]

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

Comment 4

[Håkan Waara]

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.

Comment 5

[Jean-Francois Ducarroz]

editor should not set automatically the focus when created.

Comment 6

[Håkan Waara]

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

Comment 7

[scottputterman]

moving to mozilla0.9

Comment 8

[Håkan Waara]

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

Comment 9

[Håkan Waara]

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

Comment 10

[Jean-Francois Ducarroz]

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!)

Comment 11

[Jesse Ruderman]

>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.

Comment 12

[Jean-Francois Ducarroz]

reassign to varada

Comment 13

[varada]

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

Comment 14

[David Hyatt]

My patch to 41813 covers this case.

Comment 15

[David Hyatt]

Fixed.

Comment 16

[laurel]

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

Comment 17

[Jesse Ruderman]

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

Comment 18

[Håkan Waara]

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

Comment 19

[Niels Aufbau]

This has regressed: bug 143669.