... and correspondingly nothing gets conveyed to a caller of PromptUsernameAndPassword.

This can't mean a password form control, so punting to "XP Toolkit/Widgets" component.

These aren't XPToolkit widgets. Looks like the editor folks have been handling most such bugs, reassigning.

assigning this to buster for review

this is working fine on windows with a build from friday. Can you give me any more detail? Is it any password field, or some particular one? Linux only? What build (esp. M13 or M14 code?)

confirmed that with friday's build, this is only a problem on linux. assigning to akkana to help narrow down what the heck is going on here. Akkana, if you're too busy, just let me know and I'll find someone else to help, maybe Kin? I built on linux with noisy nsGfxTextControlFrame flags on, and everything looked fine. Then I tried debugging on linux with no luck, my total lack of gdb skill. So, if you could kindly set a break point in nsTextControlFrame::WillInsertText, and verify that keystrokes are actually getting through with an appropriate string, we can see if the password control is getting any input or not. Then we'll go from there. Thanks!

The IMAP password dialog works fine in my linux build from Friday. So we need more information on how to reproduce this bug before we can know whether it's linux-only or not, and before we can start trying to debug it. Back to buster for now, until we know what's up.

akkana: in a debug build from friday, I saw this problem on linux only using the worlds simplist test case: <form> <input type=password> akkana, do you see this also?

I still see this. Linux only and buster describes it pretty well so thats really it. Originally I had seen this on the login/passwd boxes thrown thru PromptUsernameAndPassword. So whoever owns that dialog box needs to verify the same (I have no idea if that code is shared with INPUT form elements)

reassigning to akkana to get this into her queue, to help track it down, not necessarily her responsibility to fix it.

I still don't see this. Password fields, both in the imap dialog and in the simple test buster posted, are working fine for me. (I see the stars as I type.) But this sounds a lot like the problem Kin tracked down before ... maybe he has some insights.

Accepting bug.

things seem to have become worse from last night's update. Now all I see is a gray dialog box "Prompt for Database Key" and a blinking cursor in the middle somwhere (no text, no fields!)

Try updating your RDF directory, or turning off the XUL cache. Does that help?

tried that... now I can see the contents of the box... AFTER a significant wait... and the password field fills in only one * for any number of charachers...

I still can't reproduce this problem ... the last problem you mentioned above (only one '*' shows) is a bug I fixed a while ago. Gagan, can you give us steps you use to reproduce this? Are you on a branch? Or the tip?

Adding http://gagan.mcom.com:81 to URL field. This URL will put up an http username/password authentification dialog that displays the problem. Password don't seem to work with this specific case. Also I noticed that when the dialog shows up, it doesn't repaint properly unless you wiggle the mouse in front of the dialog, and my CPU seems to be pegged pretty high.

The basic auth password field does not accept focus as far as I can tell. I am running Linux with build 2000021715.

looks like bug 27784--see comments there as well. and decide which one is the dup...

I'm a little confused as to what the bug report is saying. On the one hand buster gave the world's simplest test case to demonstrate it, namely: <form> <input type=password> and then gagan gave a url of a page that requires http authentication. In the former case the password field is put up by the content itself and in the latter case it is put up by our xul dialogs. These are two separate code paths and should be treated as two separate bugs. As gagan mentioned, this looks like a dup of 27784 but that one talks about the xul case only. So can we restrict this bug report to the web-content password dialog and leave the other bug report for the xul dialog?

morse your assessment is correct and that is why I didn't mark them as dup. However since the behaviour is very similar I had mentioned the other bug on each one.

Shouldn't this be beta1, just like its companion bug 27784?

With a linux build that I made this morning, I am able to fill in passwords that appear in the content of the webpage itself. So since we agreed above that this bug is to deal with password fields in the content and that companion bug 27784 deals with password fields in browser dialogs, I'm closing this out as works-for-me.

added self to cc list. i saw this occuring while using the opt comm bits on linux [2000021808]: 1. with a new profile, go to http://slip/projects/marvin/wallet/login.html. 2. type a name in the username field. 3. attempt to type a passwd in the password field --unable to, nothing echoes.

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

added self to cc list, bug still present on Linux Build 200022108

Putting on PDT+ radar for beta1.

M14 since this is PDT+

reassign to akkana so she can try to reproduce the simple test case Akkana--grab Kin if/when you need him.

I can't reproduce this on the wallet page using the 2/23 commercial build on linux. I'm mystified as to why this happens on sairuh's machine but not on Kin's or mine. I do see it on gagan's secure page.

Sairuh and I thought this might be a gnome-vs-others issue (she runs Enlightenment, I run kde, Kin runs twm) but I tried it in gnome/enlightenment and still saw stars echoing, so it's not that. I'm curious since there a bunch of missing tags in the file: sairuh (or anyone else who sees the problem), can you try my cleaned-up version in http://warp/employees/akkana/bugs/login.html (any external people who want to try it, let me know and I'll attach the file) and see if it still has the same problems?

Perhaps you're right about the Gnome dependency. I am currently running Enlightenment without GNOME as well, and do not see the password stars.

I don't have any gnomy bits installed on the computer that RUNS mozilla, and the only gnomy bit that I have installed on the computer that displays mozilla is a package named "gnome-lib-dat" -- or similar. The password fields I can recall seeing do not allow me to enter text, with asterix or not. However, to be sure we are talking about the same thing, akkana, would you please attach your test file? :) Thanks!

akkana: I think there's some clarification needed here. I don't get the missing password stars with regular web forms; those work find. When a page uses HTTP authentication w/ the popup login window, that's where the password stars are missing.

Oh, sure, I see it too with an http authentication page. It's just in the simple page that sairuh mentions that I don't see it; and my understanding is that that's the case that's making this a PDT+.

i tried using akkana's cleaned-up page + today's opt comm bits [2000022308]. 1. copy the link to akkana's form into the Open Web Location dialog, click Open. 2. enter 'squiddy' into the username field. 3. click into the password field, try to type 'calamari' -> nothing echoes. *however* 4. on a whim, i click the Reload button (didn't click the login or check buttons beforehand, though). 5. repeat step 2 (no prob). 6. repeat step 3 -> somehow the asterisks now appear! very odd.

Compwiz -- see comments from morse. The dialog-box version of the bug has been split to a different bug. (Or, more likely, has always existed as a different bug.) Akkana, thank you for the test attachment. It works properly for me. (Asterix and all.) I clicked on the date/time URL for your attachment, typed in squiddy and calamari, and hit login -- no problems, just the (expected) complaint about "bogus.cgi". The computer that is running mozilla is linux 2.0.36 on a pentium II 266, 160 megs of ram, nice new glibc. No gnome bits are on that computer. (Save the IDL stuff. I stole that from a gnome-related project I think, in the same fashion that red hat does.) The computer that gets the mozilla display is running linux kernel 2.2.13 on a k6-2 400, 128 megs ram, nice new glibc. Only gnome-libs-data exists on the computer displaying mozilla. My window manager is sawmill 0.24; many sawmill people run gnome, so perhaps sawmill is gnome-aware, but I do not know that for sure. And, IMHO, *any* bug that prevents authentication from working should be PDT+ -- trust me, people *will* take the beta to their favorite page that requires login, and write off the entire browser if it cannot login. (Especially since it *used to work*! :) Thanks akkana, if I can be of more help, please let me know.

Just for clarification, yes the http authentication problem is a separate bug and has been broken out of this report. As for the web-content problem, I know that Sarah is running with the installer bits. And Akkana is probably running with a build that she built herself. Could this be a problem with installer versus built? Are those people for whom this works fine (myself included) all running an executible that they themselves built?

The test page Akkana attached worked for me, and I rebuild my mozilla every night from CVS. Here is a snippet of the debian/rules file I use that runs configure (most of this was stolen from the debian mozilla maintainer -- I enabled crypto and mathml, java, and oji, but left the rest alone) : $(TOP)/configure --verbose --prefix=/usr \ --disable-debug --disable-profile --enable-crypto --enable-mathml \ --disable-netcast --enable-java --enable-oji --disable-static \ --disable-tests --disable-smart-mail --enable-mailnews \ --enable-editor --enable-ldap --enable-optimize --with-pthreads \ --with-jpeg=/usr/include --with-png=/usr/include \ --with-zlib=/usr/include --with-nspr=`cd $(TOP);pwd`/build-nspr

Nope, I tested it with today's commercial bits (a tar gz file, not an installer file) as well as with my own debug build. At this point, if I'm reading all the summaries correctly, the status is: - Pretty much everyone sees this on authentication dialogs (which however are a separate bug from this one). - Quite a few people see this on the page sairuh mentioned (with its attendant html errors) - Sairuh is the only person who has seen this on my cleaned-up version of the file, and then hitting reload made it go away. I have no idea what this means as far as what might be causing the bug, just trying to make sure that I have the breakdown correct.

The address Sairuh posted is available only to you local folks -- us offsite people can't test it. :) But, your breakdown seems accurate to me Akkana.

Akkana, there's a difference between the tar file that you are using and the installer bits that sarah is using. If there are any errors in the installer's manifest of files to install, it will fail on the installer bits but still work fine on the tar file as well as on an executable that you built from sources. So is there anybody who is seeing this problem on anything other than the installer bits? And is there anybody running with the installer bits who is not seeing the problem?

Kathy and I want to request PDT re-evaluation. This is really hard to reproduce on the attached page (I'm removing the URL http://gagan.mcom.com:81 because this bug has long since morphed into a different issue) and even then it goes away on reload, which is going to make it very hard to find and test a fix.

Putting on PDT- radar for beta1.

moving to M15; set pp keyword sairuh--can you reproduce this on any other computers or just the one linux box?

hokay, i've updated the summary with what i've been seeing. this issue is that what the user enters into the password field is not being painted on the screen. the passwd itself *is* being entered, afaik, since the form (the sample used on http:// and akkana's cleaned up one) *does* accept whatever i've typed in (as expected). so, the passwd is getting entered into the form --i just cannot see it. (ultimate passwd security: no hint as to its length ;-) moreover, i couldn't reproduce this on claudius' linux machine mobay (also running gnome/enlightenment, 2.2.5-22 kernel, RH). i dunno, mebbe it's the theme i'm running. ;-P do feel free to remove the PDT marking and/or lower the severity, as needed.

I believe gagan uses enlightenment too. If it is indeed specific to the theme, it would be good to notate which one you are using so we can use it to try and recreate the problem.

the theme am using is called Pixmap (didn't select the "use custom font" option either).

finally got around to testing this with today's opt comm linux bits (2000022509)...and, lo and behold, i cannot reproduce this anymore. weird weird weird.

Sarah, since you can no longer reproduce this, should this be closed out now?

I'm going to go ahead and close this out, and hope it doesn't reappear. We still have bug 27784 on the similar problem in dialogs.

verified in 2/28 build.

looks like this has reappeared. http://quotes.freerealtime.com/frontpage/ bug 30696 sounds like this. Could one of you take a look at this URL in linux and if the problem is back re-open.

I see two text fields on that page, and I can type in both of them. Neither of them is a password field, though, and one of them is drawn under the dropdown, so there may be an unrelated layout bug here. Bug 30696 doesn't make it clear what exactly is happening. If the problem is just that the password isn't submitted properly, but you were able to type and see something echo, that isn't related to this bug. This bug is on typing not working and nothing being echoed.

asadotzler, did you mean for us to try the "member login" button on freerealtime.com? If so, that one brings up a dialog box, and is unrelated to this particular bug. The bug that deals with the dialog based passwords is bug 27784. See the comments from morse for the reasoning...

OK, 27784 is what I was looking for. Thanks. and sorry for the false alarm.