56916 - Second address field in MailCompose not getting focus by default

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect, P3)

Description

[racham]

I was trying to compose a message using today's build. Clicked on New Msg and
the new message window came up. Entered the first address and then hit Enter
(return). I don't see the curser at the second address field.

I know there have been some problems with focus. But the first address field did
get the focus i.e., when I opened the new message window..I see the curser
blinking at the first address field.

Machine windows NT. Build ID : 2000101608.

Comment 1

[racham]

I got the focus only when I used my mouse and clicked in the second recipient field.

Comment 2

[esther]

This bug has been around for a while, but got lost in another rtm bug.
Nominating for rtm as we have received several duplicated today regarding this
focus issue. If there is a bug other than 54774 that states this problem that's
a duplicate please note the bug number   This is a very high profile bug and
appears to be noticed by more and more people each day.  

Comment 3

[Jean-Francois Ducarroz]

reassign to saari

Comment 4

[kmurray1115]

Updating summary to be more accurate. Should say: Second *address* field in
MailCompose not getting focus by default.

Comment 5

[kmurray1115]

If 56340 is fixed, does it fix this one?

Comment 6

[Jean-Francois Ducarroz]

No, patch for bug 56340 doesn't fix this one. This is a separate issue for which 
we don't have a clue yet!

Comment 7

[saari (gone)]

Setting to Mozilla 1.0

Comment 8

[David Hyatt]

Nominating for rtm.  This is terrible.

Comment 9

[Peter Trudelle]

cc hyatt. what does marketing think of this?

Comment 10

[kmurray1115]

Marketing's take is the following:

Frequency: High
Severity: Low-Medium
Risk: Based on the recent regressions with the addressing widget, I believe this
is high.

The workaround lets users *make this work* so it seems like this could go out
the door. IMHO, I *do* believe we'll get some negative press on this though.

Comment 11

[saari (gone)]

I looked at this some more, and it really looks like a tree issue, reassigning
to hyatt.

Comment 12

[kmurray1115]

Peter, can you rtm [need info] this for hyatt to begin work on this?

Comment 13

[Jean-Francois Ducarroz]

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

Comment 14

[Dan Rosen]

hyatt: this seemed to end up in your hands after all (it is the bug i was trying
to find earlier).

Comment 15

[Peter Trudelle]

rtm need info/M18. This would have to have a very simple/safe fix to have any
hope of landing on the N6 branch though. If it starts to look complex/risky,
please rtm- and move on to some other rtm bug.

Comment 16

[David Hyatt]

Easy (thankfully).  Here comes the patch.

Comment 17

[David Hyatt]

Attachment: Patch attached

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

a=ben. 

Comment 19

[Stuart Parmenter]

r=pavlov

Comment 20

[David Hyatt]

Ok, pdt.

Comment 21

[Jim Roskind]

Nice concise fix!
Even though it is mostly too late for polish on the RTM branch, it is high
enough visibility polish, and seemingly an ultra-safe patch, that we'll probably
take it.
We're so close to the end, that I'd like to see even this patch landed on the
trunk first.  Please land it on the trunk asap, and then after folks have tried
sending email with it for a day (as I understand it, this will only impact the
addressing widgets, correct?), then renominate and we'll try to pull it onto the
branch on Sunday.
Thanks,
Jim

Marking need info.  Land on trunk asap.  Renominate after cooking 24 hours on trunk.

Comment 22

[Oliver Klee]

Possible dup of bug 55636 (or vice versa)?

Comment 23

[David Hyatt]

Fix has baked on trunk for 24 hours.  Putting back to rtm+ for PDT 
consideration.

Comment 24

[Jim Roskind]

Providing rtm double plus... as I said... we're stretching here... but I'm
counting the small size plus cook time to have helped (I'm assuming no
complaints, and folks are using it).  Please land on the branch asap.  We'd
really like a stable release candidate in our hands at the start of this week,
so that we can use that as a fall back, during shots at "better" candidates.

Comment 25

[David Hyatt]

Fixed on branch.

Comment 26

[varada]

Marking Verified Fixed.
WinNT 20001023
Mac  20001023
Linux 20001023