Closed Bug 141648 Opened 22 years ago Closed 22 years ago

Every other time Composer opens, cursor is not in address field

Categories

(MailNews Core :: Composition, defect, P2)

Product:
MailNews Core
Component:
Composition
Platform:
PowerPC
Mac System 9.x
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0.1

People

(Reporter: nbaca, Assigned: bugzilla)

Details

(Whiteboard: [adt2 rtm] have fix,custrtm-)

Attachments

(1 file)

Proposed fix, v1
726 bytes, patch
vparthas
: review+
Bienvenu
: superreview+
jesup
: approval+
Details | Diff | Splinter Review 
Branch and trunk build 2002-05-01: Mac 9.1 and Mac X
Mac only problem.

Overview: Every other time a Compose window opens, the cursor is not in the
address field. You have to click in the address field to see the cursor.

Steps to reproduce:
1. Create a new profile
2. Configure mail with an IMAP (or POP) account
3. Login
4. Select the Compose button

Actual Results: 
- 1st Compose: displays the blinking cursor in the address area, close the window.

2. Compose a second message and notice the cursor does not appear. You have to
click in the address area to see the cursor.
3. Continue opening and closing a new Compose window and notice that every other
time a cursor does not appear immediately in the address area. Even after an
exit/restart the same behavior remains.

Expected Results: The blinking cursor should appear in the address area by
default for every Compose window that opens.
Marking nsbeta1 because this will be confusing to users if they have to click in
the address area every other time they compose a message.

Sorry if this a dupe, I couldn't find it logged anywhere.
Keywords: nsbeta1
Note, for step 4 if you use the tab button to tab through the fields you won't
see the problem in the next compose window.  Make sure you do nothing in the 1st
compose window to see this problem in the second compose window 
With may10 beta candidate on Mac OS 10.1, I'm seeing a similar thing with cursor
placement when opening a messge composition window via mailto link or forward. 
It alternates over these three scenarios:
1.  Opens with two cursors, one in the either addressing area or subject and the
other in the body.
2.  Opens with no cursor anywhere.
3.  Opens (finally) with correct cursor placement and only one cursor.
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 rtm]
accepting
Status: NEW → ASSIGNED
When the problem occurs, if you activate another window (like mail3Pane) and the
activate the compose window again (click on it's title bar), the cursor will be
correctly blinking into the first recipient field. This is a wierd focus problem!!

cc'ing saari
this problem appends only if the focus was in the first recipient before closing
the window. Looks like on Mac, the focus is not reset when we reopen a compose
window or there is some optimization code that prevent to set the focus on a
field which it beleive has already the focus!
Attached patch Proposed fix, v1 — — Splinter Review 
This is in fact a workaround. When we close(recycle) the compose window, I'll
force the focus to be into the From: dropdown menu. Then when we reopen the
window, the focus will be set either in one of the editable field (recipient,
subject or body). I've tested the patch on Mac and Windows, still have to test
on Linux to be sure it doesn't have a side effect...
works on Linux as well.
Whiteboard: [adt2 rtm] → [adt2 rtm] have fix
Comment on attachment 84314 [details] [diff] [review]
Proposed fix, v1

The workaround looks ok but I would like to have a comment like - must fix real
focus issue for next release  . Other than that r=varada
Attachment #84314 - Flags: review+
Whiteboard: [adt2 rtm] have fix → [adt2 rtm] have fix,custrtm-
Once I have checked in this workaround, I'll either keep the bug open and
reassign it to saari or open a new bug about the real problem...
Comment on attachment 84314 [details] [diff] [review]
Proposed fix, v1

sr=bienvenu
Attachment #84314 - Flags: superreview+
Fix checked in the trunk. I;ll close this bug to allow the verification and RTM
nomination process going on...
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
1)

> works on Linux as well.

note, the cached compose window is disabled by default on linux.
The reason it is off by default is because of a similar focus issue.
see http://bugzilla.mozilla.org/show_bug.cgi?id=130581

2)

> Once I have checked in this workaround, I'll either keep the bug open and
> reassign it to saari or open a new bug about the real problem...

what's the new bug #?
esther, could you verify this on the trunk?
Keywords: adt1.0.1
adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending
Driver's approval. Pls check this in tonight, and add the fixed1.0.1 keyword.
Keywords: adt1.0.1 → adt1.0.1+, mozilla1.0.1
Priority: -- → P2
Target Milestone: --- → mozilla1.0.1
Comment on attachment 84314 [details] [diff] [review]
Proposed fix, v1

please check into the 1.0.1 branch ASAP. once landed remove the 
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword

make sure to keep the bug open for a real solution as per previous comments
Attachment #84314 - Flags: approval+
Fix checked in the branch. I'll reopen the bug once verified
Keywords: mozilla1.0.1+ → fixed1.0.1
Using branch builds 20020610 on winxp, mac os10.1 and linux, the final result is
that the cursor is in the correct place.  However, when watching the Compose
window come up on win and mac os10.1 you will see the cursor flash briefly in a
location other than/or in addition to the correct location but that is just for
a moment then it settles in the correct location.

New Compose window subsquent times = briefly in body then lands in To: field
Forward = briefly in body then lands in To: field
Reply = briefly at beginning of Formatting toolbar, then lands in Body

Please let me know if the as is is OK for the nomination.  If so, I can log a
new bug for the lag and verify this one for the final location of the cursor.
the cursor blinking is a side effect of the workaround but this is acceptable
and you can close this bug as verifyed. Once you do that, I'll reopen it for the
real fix...
verified on branch
Status: RESOLVED → VERIFIED
jean-francois, procedure is for me to replace fixed1.0.1 with verified1.0.1, but
since you are going to reopen this bug I'm not sure what I'm suppose to do other
than what I already did which was to resolve it as verified.  What else should I
do with this bug?
ok, I'll open a new bug to avoid confusion...
Keywords: fixed1.0.1 → verified1.0.1
On Mac 10.1.3 recent few days branch builds - I see 2 cursors sometimes. Now
after reading this (thanks Esther) I see that it actually happens every other
time. Also fast retrieving Compose window after changing folders (or other not
finished action) causes no cursor at all. We can use keyboard or mouse.
Product: MailNews → Core
(In reply to comment #22)
> ok, I'll open a new bug to avoid confusion...

If anyone who participated in this bug is still around... it seems that the workaround didn't last, or something else has happened to duplicate similar symptoms (see bug 282669).

Did Jean-Francois ever file that new bug for a better fix? If so, I haven't been able to find it.

Cheers
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: