Closed Bug 18130 Opened 21 years ago Closed 20 years ago
focus/caret not set in mail login dialog
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.
Forgot this: using 1999-11-05-08m11 commerical build on mac OS 8.5.1
Sounds like an editor issue
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?
assigning this to kin for review and setting to 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
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.
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.
So long as you can get focus by clicking, this is not essential for beta.
Whiteboard: [TESTCASE NEEDED] → [TESTCASE NEEDED][PDT+]
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.
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?
Status: ASSIGNED → RESOLVED
Closed: 20 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
You need to log in before you can comment on or make changes to this bug.