password dialog does not automatically grab focus

RESOLVED WORKSFORME

Status

SeaMonkey
MailNews: Message Display
--
major
RESOLVED WORKSFORME
18 years ago
5 years ago

People

(Reporter: blizzard, Unassigned)

Tracking

({access})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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.

Updated

18 years ago
QA Contact: esther → laurel

Comment 1

18 years ago
This problem occurs on "Find in this page" dialog, "Open Web Location"
dialog and... maybe all dialog.

Comment 2

18 years ago
Isn't this a dup of bug 50128?

Comment 3

18 years ago
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.

Comment 4

17 years ago
A related bug has been fixed, this should work now.

Comment 5

17 years ago
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.

Updated

17 years ago
OS: Linux → All
Hardware: PC → All

Comment 6

17 years ago
*** Bug 76581 has been marked as a duplicate of this bug. ***

Comment 7

17 years ago
worksforme, win32-installer 2001041920, win2k

Comment 8

17 years ago
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

Comment 9

17 years ago
*** Bug 83988 has been marked as a duplicate of this bug. ***

Comment 10

17 years ago
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.

Updated

16 years ago
Severity: minor → major
Keywords: access

Comment 11

16 years ago
still works for me, 2001-1001-03 win32 installer on win2k. I haven't noticed
this problem since April.

Comment 12

16 years ago
I can't reproduce this either.  marking worksforme.  If someone is still seeing
this, please reopen.
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 13

16 years ago
Haven't had any problems with this lately - worksforme with current builds.
Status: RESOLVED → VERIFIED

Comment 14

16 years ago
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 → ---

Comment 15

16 years ago
worksforme again, build 2001103003

Comment 16

16 years ago
hey cool :-)

Comment 17

16 years ago
Mostly and today is wfm, but I saw absence of focus on previous builds.
I keep eyes on it for a while.

Comment 18

16 years ago
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?

Comment 20

16 years ago
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

Comment 21

16 years ago
*** Bug 169628 has been marked as a duplicate of this bug. ***

Comment 22

16 years ago
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 ...

Comment 23

15 years ago
pulled it agin from cvs today and compiled, and now it's gone fro me again :-)
all works as I expect it

Updated

15 years ago
Blocks: 154188

Comment 24

15 years ago
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.

Comment 25

15 years ago
Created attachment 100145 [details]
Wrong Focus on Sending Password Prompt

Comment 26

15 years ago
Adding myself to CC. 

NOTE: I blacked out some data (as you can see) on the screenshot

Comment 27

15 years ago
Is this still happening on a current build as I'm sure it was fixed in bug 172194

Comment 28

15 years ago
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

Comment 29

15 years ago
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).

Comment 31

15 years ago
*** Bug 81439 has been marked as a duplicate of this bug. ***

Comment 32

15 years ago
*** Bug 172038 has been marked as a duplicate of this bug. ***

Comment 33

14 years ago

*** This bug has been marked as a duplicate of 164537 ***
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago14 years ago
Resolution: --- → DUPLICATE

Updated

14 years ago
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 34

14 years ago
*** Bug 228407 has been marked as a duplicate of this bug. ***

Comment 35

14 years ago
*** Bug 164537 has been marked as a duplicate of this bug. ***

Comment 36

14 years ago
*** Bug 198224 has been marked as a duplicate of this bug. ***

Comment 37

14 years ago
*** Bug 182269 has been marked as a duplicate of this bug. ***
*** Bug 241434 has been marked as a duplicate of this bug. ***

Comment 39

14 years ago
(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

Updated

13 years ago
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?

Comment 41

9 years ago
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
Last Resolved: 14 years ago5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.