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

VERIFIED FIXED in Thunderbird 3.0b1


MailNews Core
15 years ago
9 years ago


(Reporter: esther, Assigned: Przemyslaw Bialik)



Thunderbird 3.0b1

Firefox Tracking Flags

(Not tracked)



(1 attachment, 1 obsolete attachment)



15 years ago
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.


15 years ago
Keywords: regression
Product: MailNews → Core
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody

Comment 2

10 years ago
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:
Filter on "Nobody_NScomTLD_20080620"
QA Contact: esther → composition
Product: Core → MailNews Core

Comment 4

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


10 years ago
Duplicate of this bug: 275189

Comment 6

10 years ago
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)
Summary: Context menu Compose Mail To places focus in body instead of subject → Compose HTML Mail with pre-filled Recipient (e.g. mailto:) places focus in body instead of subject

Comment 7

9 years ago
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

9 years ago
Created attachment 347327 [details] [diff] [review]
Proposed fix v1

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

If approved please credit Rod Whiteley in the checkin comment.
Attachment #347327 - Flags: review?(mkmelin+mozilla)

Comment 9

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

Comment 10

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

Comment 11

9 years ago
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

9 years ago
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

9 years ago
Created attachment 348797 [details] [diff] [review]
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 ;)
Assignee: nobody → firefox
Attachment #347327 - Attachment is obsolete: true
Attachment #348797 - Flags: review?(mkmelin+mozilla)
Attachment #347327 - Flags: review?(mkmelin+mozilla)

Comment 14

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

Looks good, thx for the patch! r=mkmelin
Attachment #348797 - Flags: review?(mkmelin+mozilla) → review+


9 years ago
Hardware: PC → All


9 years ago
Keywords: checkin-needed
Checked in:
Last Resolved: 9 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.0b1

Comment 16

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

Comment 17

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


9 years ago
Blocks: 360488

Comment 18

9 years ago
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

9 years ago
Yes seamonkey needs it's own fix

Should be trivial if someone's interested in doing it - in another bug though.
Attachment #348797 - Attachment description: Proposed fix v2 → Proposed fix v2 [Checkin: Comment 15]
(In reply to comment #19)
> Should be trivial if someone's interested in doing it - in another bug though.

I filed bug 467244.
Blocks: 467244
No longer blocks: 360488
You need to log in before you can comment on or make changes to this bug.