207527 - Compose HTML Mail with pre-filled Recipient (e.g. mailto:) places focus in body instead of subject

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[esther]

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.

Comment 1

[(not reading, please use [e-mail] instead)]

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

Comment 2

[Rod Whiteley]

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

Comment 3

[Serge Gautherie (:sgautherie)]

Filter on "Nobody_NScomTLD_20080620"

Comment 4

[Mike Cowperthwaite]

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

Comment 6

[Mike Cowperthwaite]

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)

Comment 7

[Przemyslaw Bialik]

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

Comment 8

[Przemyslaw Bialik]

Attachment: Proposed fix v1

- adds settimeout to AdjustFocus
- updates previous comment based on my testing

If approved please credit Rod Whiteley in the checkin comment.

Comment 9

[Przemyslaw Bialik]

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

Comment 10

[Magnus Melin [:mkmelin]]

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

Comment 11

[Przemyslaw Bialik]

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.

Comment 12

[Magnus Melin [:mkmelin]]

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.

Comment 13

[Przemyslaw Bialik]

Attachment: Proposed fix v2 [Checkin: Comment 15]

like this ? (seems to work well)

(good idea, the code is better and maybe again we would fix other bug by accident ;)

Comment 14

[Magnus Melin [:mkmelin]]

Comment on attachment 348797 [details] [diff] [review]
Proposed fix v2
[Checkin: Comment 15]

Looks good, thx for the patch! r=mkmelin

Comment 15

[Mark Banner (:standard8)]

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

Comment 16

[Philip Chee]

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

Comment 17

[Przemyslaw Bialik]

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

Comment 18

[Mike Cowperthwaite]

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.

Comment 19

[Magnus Melin [:mkmelin]]

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.

Comment 20

[Serge Gautherie (:sgautherie)]

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

I filed bug 467244.