31092 - "Enter master password" dialogue->cursor blinks but wont accept text

Status: VERIFIED DUPLICATE of bug 27784

(SeaMonkey :: Passwords & Permissions, defect, P3)

Description

[Gwyn Judd]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.14 ppc; en-US; m14)
BuildID:    2000030215

When the password manager asks for your master password it puts up a dialogue
box. The cursor in the text box blinks but when you type it doesn't accept text
and you have to click in it to make it accept text.

Reproducible: Always
Steps to Reproduce:
(This is assuming you use the password manager to log you into bugzilla)

1. Log out of bugzilla
2. Open the preferences dialogue and delete the password manager entry for
bugzilla. (Note it will put up a dialogue box asking for your master password
here, however the propblem I am describing *does not occur* with this dialogue,
for me anyway).
3. Quit mozilla
4. Restart
5. Go to the above URL and log in again
6. When it asks you if you want to store the password click "yes"
7. When it brings up the master password dialogues, notice how the cursor in the
text box is blinking.
8. Attempt to type in your password.	
9. Click in the text box
10. Enter your password (it will work this time)


Actual Results:  The text is not entered (ie. the asterisks do not appear for
each character you type).

Expected Results:  If the cursor is blinking, you would expect it to accept text

Comment 1

[Gwyn Judd]

*** Bug 31093 has been marked as a duplicate of this bug. ***

Comment 2

[Stephen P. Morse]

Sarah, can you confirm this?  If this is true, it's pretty serious and needs to 
be nominated for beta1 immediately.

Comment 3

[sairuh (rarely reading bugmail)]

yes, i'm able to repro this using the opt comm bits on linux, 2000.03.09.09.

Comment 4

[Stephen P. Morse]

Sarah, what about linux non-commercial?  Also what about win32?

Comment 5

[sairuh (rarely reading bugmail)]

not a problem on winNT (opt comm bits). and, strangely enough, not a problem
with the mozilla [non-comm] bits on linux [2000.03.03.09].

Comment 6

[Stephen P. Morse]

So let me see if I can summarize:

      mozilla  commercial
winNT   OK         OK
linux   OK        FAIL
mac    FAIL         ?

Is this correct?  And what is the case for mac commercial?

Comment 7

[Stephen P. Morse]

Also I'm a bit confused by this report.  The reporter is claiming that the 
failure is occuring with a linux OS on a mac platform.  Is there such a thing or 
is this a typo?

Comment 8

[sairuh (rarely reading bugmail)]

bug 31198 has really been hindering me for most any kind of testing on the mac
(although it affects all platforms).

btw, i've only tested commercial winNT, not mozilla.

Comment 9

[sairuh (rarely reading bugmail)]

yep, just verified that this is not a problem on winNT mozilla [non-comm].

Comment 10

[sairuh (rarely reading bugmail)]

finally got a decent MacOS build... tested the mozilla [non-comm, opt] bits
2000.03.09.13 --and did *not* run into the problem of being unable to type while
the cursor is blinking in the master passwd dialog.

Comment 11

[Gwyn Judd]

A clarification since there seems to be some confusion. This is not a MacOS
platform build problem as far as I know, it is a linux problem. I am running
linuxppc, a version of linux that runs on powerpc chips including pretty much
any Powermac. FYI there are at least three other distros that will run on Macs
including YellowDog linux, Debian and Mac68k Linux.

Comment 12

[Stephen P. Morse]

OK, let me try that summary again.  From what Sarah and b.judd just said, mac is 
not and never was a problem.  But I'm a bit confused now as to what the linux 
row should look like.  According to Sarah, this is  a problem on the 
commercial linux build, not the mozilla linux build.  But b.judd who reported 
this is outside of netscape so is obviously running the mozilla linux build and 
seeing the failure.  Need some consensus here! 

               mozilla   commercial
winNT            OK          OK
linux (b.judd)  FAIL         n/a
linux (sairuh)   OK         FAIL
mac              OK          OK

Comment 13

[sairuh (rarely reading bugmail)]

dunno what to say... except i notice a typo on my 12:48 entry today --the
mozilla bit i used had the 2000.03.09.09 timestamp, same as the commercial bits
tested, 2000.03.09.09.

Comment 14

[Stephen P. Morse]

Well now that we have the matrix, I think it's clear that this bug is a dup of 
27784.  That bug was linux-only and originally said that you couldn't type into 
the password field of browser-generatated dialogs.  There has been some interim 
hacking of that bug so that you can now type into the password field (which 
de-esculated it from PDT+) but it left some uglies in its place -- like all 
dialogs coming up objectionably bigger, etc.  I strongly suspect that the 
symptom described here is another one of the uglies that the hacked fix 
introduced.  There is acknowedgably more work to be done on that bug, but at 
least it's not longer a beta blocker.

*** This bug has been marked as a duplicate of 27784 ***

Comment 15

[Gwyn Judd]

Wouldn't it be better to mark it as "Depends on.." rather than duplicates?

Comment 16

[Stephen P. Morse]

Unfortunately that bug has morphed from its initial symptoms of "text fields i 
browser forms not being accessible under linux" to "cpu usage is pegged".  But 
in spite of that, what the bug is really saying in my opinion is that dialogs 
with passwords fields don't work properly on linux.  Under that interpretation, 
this bug is a dup of that one.

Comment 17

[sairuh (rarely reading bugmail)]

verif.