Using branch and trunk builds 20030528 on winxp, macosx and linux the focus for the context menu "Compose Mail To" opens the compose window with from and to populated, but the focus is in the body of the message instead of the Subject line. Regression from 7.02. Not sure when this broke, was like this in the 4-29 build. Inthe 3-31 build I had 2 cursors one in the subject and one in the body, the subject cursor was the focused one. 1. launch app 2. open mail 3. click on an email address in the header of a message. 4. Select "Compose Mail To" option Result: Compose window opens, cursor focus is in body of message Expeced : Compose window opens, cursor focus should be in Subject.

sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.

Problem still exists in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110404 Thunderbird/3.0a1pre Also seen using Write button in address book, or mailto link with an address but no subject. FWIW, in MsgComposeCommands.js, at the end of function ComposeFieldsReady, changing AdjustFocus() to setTimeout(AdjustFocus, 0) makes the problem go away, though this is probably not the best solution. See also: http://forums.mozillazine.org/viewtopic.php?t=599804

Filter on "Nobody_NScomTLD_20080620"

Note that this bug only occurs if the identity used for the composed message has "Compose in HTML" enabled. xref bug 275189.

Updating the summary to reflect the common thread between this bug and bug 275189: If the composition window has its Recipient field filled in when it opens, and it's an HTML compose window, then the focus is in the Body rather than the Subject. This happens with: - right click on an email link (header or body), select Compose Mail To (default identity for that account has HTML Compose) - click a mailto: link from anywhere (default identity for primary account has HTML Compose) - compose a message to a newsgroup (default identity for news account has HTML Compose)

Rod, could you attach the patch regarding your comment 2 ? html mode probably just needs timeout to focus subject properly, similarly to the case little higher in the code: > // need timeout for reply to work > if (gMsgCompose.composeHTML) > setTimeout(loadHTMLMsgPrefs, 0);

- adds settimeout to AdjustFocus - updates previous comment based on my testing If approved please credit Rod Whiteley in the checkin comment.

I could probably check for html mode but maybe it isn't necessary... let's wait for Magnus comment.

Why exactly is this needed? (The earlier too.) What happens in AdjustFocus? And why the change from reply to forward?

AdjustFocus() focuses first empty field (from address through subject and ending on body) but without settimeout when writing to sb (in html mode) the body gets focus and not subject (there are times when 2 cursors are blinking but never subject one has focus). Earlier case is only observed when doing forward - without settimeout loadHTMLMsgPrefs is not called e.g. you get default white background and not blue in compose.

How about setting up the html prefs in NotifyComposeBodyReady instead, and doing a final AdjustFocus() after that? And getting rid of the hacky setTimout in the progress.

like this ? (seems to work well) (good idea, the code is better and maybe again we would fix other bug by accident ;)

Comment on attachment 348797 [details] [diff] [review] Proposed fix v2 [Checkin: Comment 15] Looks good, thx for the patch! r=mkmelin

Checked in: http://hg.mozilla.org/comm-central/rev/d4e0de2ef9b9

Do we need this in SeaMonkey as well (MsgComposeCommands.js is forked)?

If it is forked and you experience this bug then yes.

I can verify this is fixed for TB -- Gecko/20081128 Shredder/3.0b1pre. I won't change the status, tho, since the question in coment 16 is still open.

Yes seamonkey needs it's own fix http://mxr.mozilla.org/comm-central/source/mailnews/compose/resources/content/MsgComposeCommands.js#1166 Should be trivial if someone's interested in doing it - in another bug though.

(In reply to comment #19) > Should be trivial if someone's interested in doing it - in another bug though. I filed bug 467244.