133442 - Send Page does not always position cursor in To: field

Status: RESOLVED EXPIRED

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Andrei Boros]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

Whenever one views a page, if I go File->Send Page, the New message window is
opened with that page attached and the link displayed in the msg body. 
Netscape 4.x behaviour is to place the cursor in the "To:" field when this
window becomes active, so user can enter the email address directly without any
additional steps. 
This happens in mozilla too, but only sometimes.
Other times, the New MSG window does not place cursor in any control at all and
user must manually place it an input control.

I could not establish a rule that determines this yet. 

For example I was doing this for the past 30 min. or so and out of about 30
pages I wanted to send, roughly half of them placed the cursor where they
should, the other didn't.


Reproducible: Sometimes
Steps to Reproduce:
1. have a page in the browser
2. File->Send Page. Cursor should be in To: field. If not, no field has cursor.
3. repeat 1,2 several times.

Actual Results:  New MSG window works fine except the above described situation.
It introduces an additional step that muight be annoying to the user.

Expected Results:  Always place cursor in New MSG box when this window first opens.

Pages tested were mostly in .cz TLD and contained just HTML, some had
Javascript, some had frames, etc.

Comment 1

[Olga]

WFM on Win2K, trunk build at 03-28-02. Would you please check on latest build?

Comment 2

[Alexander Opitz]

WFM with 2002040403 on Win95

Reporter can you please use a newer nightly build for testing? And add a comment
here?

Comment 3

[R.K.Aa.]

Duplicate of bug 130581? If so, this was verified fixed on April 26th.
Andrei Boros: Can you please try with a later build?

Comment 4

[Andrei Boros]

Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.1) Gecko/20020826

Works, but only partially. 
Here is why:
1) a signiture is defined
2) the buildup of the mail composition window is quite slow (amd athlon 650mhz
with processor idle > 90%), using a camera playback, I measured it to about
0.5sec from the window outline until the cursor is in the To: field.
3) it is clearly visible how the cursor is first positioned in the body area of
the composition window, then it is moved to the To: field. 
4) as usually I am quite prompt and my typing is pretty good, I often found
myself writing incomplete addresses in the To: field because the first one or 2
characters get written in the body area, which is then very annoying.

The animated gif attached to bug #130581 perfectly illustrated the original issue.


Current behaviour:
1) window is created
2) caret is placed in email body as visible
3) caret is moved to To: field and becomes invisible as it arrives there, being
th next state of it's blinking cycle, but is seen as blinking later.

As such, cursor placement sequence is misleading until a stable blinking cursor
can be seen in the To: field.

Comment 5

[Pascal Chevrel:pascalc]

confirmed with build 2003032104 WinXP

1 go to http://bugzilla.mozilla.org/attachment.cgi?id=77485&action=view
2 right click and select "sent to..."

expected result : caret should be in the to field
actual result : no caret at all

Apparently, the problem happens only when you select the option from the context
menu, not when you select it from normal menus.

It happens with local pages too.

Comment 6

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420