Closed Bug 18130 Opened 25 years ago Closed 25 years ago

focus/caret not set in mail login dialog

Categories

(SeaMonkey :: MailNews: Message Display, defect, P3)

Product:
SeaMonkey
Component:
MailNews: Message Display
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: laurel, Assigned: saari)

References

Details

(Keywords: helpwanted, platform-parity, Whiteboard: [TESTCASE NEEDED][PDT+]) 

When a mail login dialog appears, there is no cursor and no focus given to the
dialog.  User must click in dialog's text input field before typing.

1.  Launch Messenger.
2.  Select a mail inbox which doesn't have password remember pref on.
3.  Click Get Msg.

Result:  focus isn't given to the login dialog.
QA Contact: lchiang → laurel
Forgot this:  using 1999-11-05-08m11 commerical build on mac OS 8.5.1
Assignee: phil → beppe
Sounds like an editor issue
Whiteboard: [TESTCASE NEEDED]
might be a gfx text control problem.  is it mac-specific, or xp?  could somebody
build a little test case from that dialog and attach it to this bug for me to
look at?
Yes, this is Mac specific.
david m. seems to know of mac specific a bug where we loose focus of the text
area, because the password dialog window looses focus.

adding david m and danm to the cc list.
see bug 12051 which saari owns. the basic problem is that I give the widget
focus and when the window actives it steals the focus from the editfield.
should this go to saari?
Assignee: beppe → kin
assigning this to kin for review and setting to m14
Status: NEW → ASSIGNED
Accepting bug.
Target Milestone: M14
forgot thhe m14 part
Re: TEST CASE.  We don't have the expertise in our mail QA group to write an
html dlg/sample.  Also, the time factor - the bug can be seen just by bringing
up the mail dialog.  Thanks.
This affects the AIM team also. ccing andreww,scalkins
Group: netscapeconfidential?
unless something has changed, you shouldn't mention the AIM group in a
publically accessible bug.  Since you did, I'm moving this to "netscape private"

Please correct me if I'm wrong.
we're setting focus by calling a js document.getElementById("foo").focus()
Where foo is the id of the input field.  If the page is simply a form with
something to set focus, it works ok, but where there are a lot of overlays and
styles involved, it seems to "steal" the focus, because it looks like it has
focus for an instant, then the field "flashes" and the focus is gone.  So
building a simple test case is going to be tricky
Daver said it's ok to mention the word "AIM" in ref to bugs in Bugzilla, (we
just should not put details of how it shows itself in Aim in Bugzilla). There
should be an email to seamonkey-internal on this soon.
Summary: [PP] focus/cursor not set in mail login dialog → [PP] focus/caret not set in mail login dialog
Changing summary from "cursor" to "caret"
Adding "pp" keyword.
Keywords: pp
Group: netscapeconfidential?
Chris -- I think this may be a focus issue -- can you help take a look at this?
Assignee: kin → saari
Status: ASSIGNED → NEW
Target Milestone: M14
Argh! This is a nasty bug... basically we're setting focus before the dialog is 
shown, which on MacOS means the focus event never reaches the text field.

I'm going to put it on my M14 list, but I'm not sure I can fix it in that 
timeframe.
Status: NEW → ASSIGNED
Target Milestone: M14
Summary: [PP] focus/caret not set in mail login dialog → focus/caret not set in mail login dialog
This is a general problem on MacOS with dialogs where setting the initial focus 
from the onload handler fails because the dialog is not yet visible and the Mac 
event dispatch code doesn't deal with dispatching events to non-visible things.
Keywords: beta1
So long as you can get focus by clicking, this is not essential for beta.
Whiteboard: [TESTCASE NEEDED] → [TESTCASE NEEDED][PDT+]
Blocks: 26981
If it's  not essential for beta - why is it still marked pdt+?
Has anyone found a temporary workaround? (setTimeout - ugh)

*** Bug 26445 has been marked as a duplicate of this bug. ***
There are no good temp workarounds IMO. Marking helpwanted simply because I don't 
think I'll have time to deal with this before Tues.
Keywords: helpwanted
To be more clear, clicking to set focus works fine

On and before Linux build 2000.02.10.15, I have a blinking cursor in the
password field, but keystrokes don't go there until I click in the field.  Am I
alone with that, or why is this a Mac-only issue?
Fixed
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
To answer zach's last comments about linux:
Trying with today's mozilla build on linux rh6.0 sometimes I get full focus
where I can start typing without a click in the password field and sometimes I
don't.  I'm thinking that may be a symptom of bug #27717, because often when I
hide&expose the password dialog I'll be ok with full focus again.

We have no mac builds for QA today, so will be waiting for verification anyway
and hopefully 27717 will be fixed by then for verification again on all
platforms.
FYI, linux has a seperate bug on this, 24370

Thanks, saari, for the info on the linux only bug.  I'll continue with this one
then as Mac only.
OK using 2000-02-15-09m14 commercial build on mac OS 9.0
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.