Closed Bug 56916 Opened 24 years ago Closed 24 years ago

Second address field in MailCompose not getting focus by default

Categories

(MailNews Core :: Composition, defect, P3)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: racham, Assigned: hyatt)

References

Details

(Whiteboard: [rtm++])

Attachments

(1 file)

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.
I got the focus only when I used my mouse and clicked in the second recipient field.
OS: Windows NT → All
Hardware: PC → All
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.
reassign to saari
Assignee: ducarroz → saari
Updating summary to be more accurate. Should say: Second *address* field in MailCompose not getting focus by default.
Summary: Second email field is not getting focus by default → Second address field in MailCompose not getting focus by default
If 56340 is fixed, does it fix this one?
No, patch for bug 56340 doesn't fix this one. This is a separate issue for which we don't have a clue yet!
Setting to Mozilla 1.0
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Nominating for rtm. This is terrible.
Keywords: rtm
cc hyatt. what does marketing think of this?
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.
I looked at this some more, and it really looks like a tree issue, reassigning to hyatt.
Assignee: saari → hyatt
Status: ASSIGNED → NEW
Peter, can you rtm [need info] this for hyatt to begin work on this?
*** Bug 57329 has been marked as a duplicate of this bug. ***
QA Contact: esther → laurel
hyatt: this seemed to end up in your hands after all (it is the bug i was trying to find earlier).
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.
Whiteboard: [rtm need info]
Target Milestone: mozilla1.0 → M18
Easy (thankfully). Here comes the patch.
Status: NEW → ASSIGNED
Attached patch Patch attached (deleted) — Splinter Review
r=pavlov
Ok, pdt.
Whiteboard: [rtm need info] → [rtm+]
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.
Whiteboard: [rtm+] → [rtm need info]
Possible dup of bug 55636 (or vice versa)?
Fix has baked on trunk for 24 hours. Putting back to rtm+ for PDT consideration.
Whiteboard: [rtm need info] → [rtm+]
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.
Whiteboard: [rtm+] → [rtm++]
Fixed on branch.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking Verified Fixed. WinNT 20001023 Mac 20001023 Linux 20001023
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: