Closed Bug 52436 Opened 24 years ago Closed 12 years ago

password dialog does not automatically grab focus

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: blizzard, Unassigned)

References

Details

(Keywords: access)

Attachments

(1 file)

Wrong Focus on Sending Password Prompt
22.48 KB, image/jpeg
Details
This is a regression. It used to be that when a password dialog popped up for imap servers that it would grab focus and you could just type in your password. Now when it pops up, the cursor is blinking like it has focus but you have to click in the box to give it focus.
QA Contact: esther → laurel
This problem occurs on "Find in this page" dialog, "Open Web Location" dialog and... maybe all dialog.
Isn't this a dup of bug 50128?
They all work fine, just make sure your cursor is in the dialog, as there is a different bug with events not going to a window when the cursor isn't in the window.
A related bug has been fixed, this should work now.
Now (2001041804/win32-installer) the dialog box has focus, but the password entry field does not. So you have to click on the field to get the blinking cursor there. This was working better until about a week ago.
OS: Linux → All
Hardware: PC → All
*** Bug 76581 has been marked as a duplicate of this bug. ***
worksforme, win32-installer 2001041920, win2k
This is for the general password dialog, nothing IMAP specific - changing summary to reflect this. -> Sspitzer
Assignee: putterman → sspitzer
Summary: imap password dialog does not grab focus → password dialog does not automatically grab focus
*** Bug 83988 has been marked as a duplicate of this bug. ***
I might have a fix for this, unfortunately I'm having problems reproducing it. Blizzard (or anyone else), are you still seeing this? If so, let me post my proposed fix and see if it fixes it.
Severity: minor → major
Keywords: access
still works for me, 2001-1001-03 win32 installer on win2k. I haven't noticed this problem since April.
I can't reproduce this either. marking worksforme. If someone is still seeing this, please reopen.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Haven't had any problems with this lately - worksforme with current builds.
Status: RESOLVED → VERIFIED
Okay, now this is back again on the trunk (in win2000 at least) sometime in the last week. Currently running 2001101603 win32-installer, will try today's when one is available.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
worksforme again, build 2001103003
hey cool :-)
Mostly and today is wfm, but I saw absence of focus on previous builds. I keep eyes on it for a while.
Mozilla 1.1b nightly build Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.1b) Gecko/20020901 can not reproduce
I still see this with multiple mail accounts on a RedHat 7.3 system running Ximian Gnome. Saari, what's the bug you mentioned in comment #3?
I'm not sure if we have a newer bug, but a few of us are definitely seeing this behavior on the current commercial trunk, but with a twist... the first/default account password dialog seems to have no problem with focus, but password dialog encountered on another account in the profile ALWAYS causes a focus problem for me. My situation is that the first/default account has "check mail at startup" enabled and all other accounts do not. In any case, it's bugging me.
Keywords: nsbeta1
*** Bug 169628 has been marked as a duplicate of this bug. ***
one more thing (but I don't know, if this really related...) I'm not longer able, to switch in the password-dialog for web-pages between username and password with TAB-key -> so I have to select the password-field with the mouse. But the username-filed grabs focus automatically ...
pulled it agin from cvs today and compiled, and now it's gone fro me again :-) all works as I expect it
Blocks: 154188
May I mention, that I have this recurring from time to time on Linux, that you have to click into the "Password Field" when *getting* Messages to actually type the password in. But what has been always there, is that if I want to *send* a message, and I hit "Send" the upcoming Password Prompt Dialog has never focus. So I need to click on the "Password Prompt" Window border to have it getting focus. When it comes up, it isn't even an active window but rather the window borders are greyed. WindowManager is Sawfish on Gnome-1.4.
Adding myself to CC. NOTE: I blacked out some data (as you can see) on the screenshot
Is this still happening on a current build as I'm sure it was fixed in bug 172194
The BUG you mention works for me. But this build has as well the bug of the password prompt having the no focus. So I do not think that , these 2 Bugs are related to each other
Mail triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
The problem exists in build 2002122608 (on Windows) with password dialog appearing first time (just after creating first mail account).
*** Bug 81439 has been marked as a duplicate of this bug. ***
*** Bug 172038 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 164537 ***
Status: REOPENED → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 228407 has been marked as a duplicate of this bug. ***
*** Bug 164537 has been marked as a duplicate of this bug. ***
*** Bug 198224 has been marked as a duplicate of this bug. ***
*** Bug 182269 has been marked as a duplicate of this bug. ***
*** Bug 241434 has been marked as a duplicate of this bug. ***
(In reply to comment #38) > *** Bug 241434 has been marked as a duplicate of this bug. *** I don't know whether bug 241434 is really a duplicate. The behaviour described here talks (mainly) about IMAP and the fact that the password dialog shows up but the input field does not grap focus. 241434 states that the password dialog opens in background for outgoing mail via SMTP. To have the text here, the description of 241434 follows: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040421 At the mail (SMTP) server I use authentication (username & password) for login. If the password has not already been provided, when sending an e-mail, the password dialog opens in the background. I have to click on the main mail window to bring the password dialog to front. It seems that the mail password dialog window has the "Mail & Newsgroup" window has parent component but it should be the message window of the message that I am trying to send. Reproducible: Always Steps to Reproduce: 1. Do a fresh start up of mozilla 2. Open the Mail & Newsgroups window 3. Compose an e-mail 4. Send to an SMPT server with user authentication (username, password) enabled Actual Results: Mail password dialog opens in background Expected Results: Mail password dialog should open in foreground I experience this behaviour since mozilla 1.6
Product: Browser → Seamonkey
Assignee: sspitzer → mail
Status: REOPENED → NEW
Priority: P3 → --
QA Contact: laurel → search
I just found this by triage. Is this one still valid at all? I haven't played extensively with SeaMonkey, but in Thunderbird have not seen this issue lately. Should we close as wfm?
can you reproduce?
Assignee: mail → nobody
QA Contact: search → message-display
(In reply to comment #41 and private email) > can you reproduce? Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3pre) Gecko/20090809 SeaMonkey/2.0b2pre - Build ID: 20090809002400 I haven't noticed it; and on my installation, the Cookie dialog ("This site wants to modify an existing cookie") and the "Are you sure you want to close all 54 tabs?" dialog both come up with focus (both are Browser dialogs, however, not MailNews dialogs). I don't use IMAP so I can't test the dialog in comment #0. The "Open web location" dialog (comment #1, another Browser dialog) comes up in focus, with the URL field pre-filled and selected. For the test in comment #39: I don't use authenticated SMTP. My POP servers use preset usernames & passwords, and I am loath to unset them in the Password Manager. Conclusion: No, I can't reproduce, however it is quite possible that I didn't try the exact "misbehaving" dialog.
Closing WFM.
Status: NEW → RESOLVED
Closed: 21 years ago → 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: