Both with and without single signon, password dialogs don't display the asterisks in the password field. Also, if single signon is on, the checkmark for "Remember password" doesn't get checked when you lick on it. The latter is alos true for MailNews password dialogs (although there the asterisks are shown when you type in the password field). To reproduce: 1. Go to password authenticated site, eg, http://dmoz.org/editors 2. Type in password field Actual result: no asterisks Expected result: asterisks as you type Linux build 2000.02.16.09

The password field problem is bug 27784. But the checkmark problem isn't covered there, so I'll leave this open. Change summary.

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

Putting on PDT+ radar for beta1.

Ben?

Don? ;) sounds like a problem with the password text input field itself rather than a problem with this dialog. works4me on windows.

On Linux build 2000.02.21.08, <INPUT type=password> as well as the MailNews password dialogs take focus and show *'s as you type. Only the htaccess auth dialog has trouble.

Must fix by 03/03 or moving to pdt-.

Just want to avoid some confusion here. Both ben's and zach's comments above talk about the password-field problem. That is a separate bug -- namely bug 27784 (as zach pointed out in his earlier comment). This bug is only about the checkbox not working.

Problem is a repainting issue. If you click on the unchecked checkbox, nothing happens. Then if you bring another window over the dialog and then remove it, the checkmark appears. Similarly if it was already checked and you click on it, nothing changes until you force it to repaint by hiding and then unhiding the dialog. An even simpler way to demonstrate this is to click on the unchecked checkbox, then drag the dialog so that the checkbox goes offscreen, and then drag it back. Note that now the checkbox is checked.

Below is a simplified test case. It displays just a checkbox and nothing more. No javascript. If I copy it to chrome/global/content/default/commonDialog.xul, and go to dmoz.org/editors, the checkbox comes up but it displays the problems described in this report (appears as though it can't be checked until you force a repaint). Now if instead of bringing this up as an http-authentication dialog, I type in the file url for it directly in the browser's url line, the checkbox dialog again comes up. But this time it works perfectly fine. From this I conclude that this is most likely a threading problem. The dialog works fine when on the UI thread but not on the http thread.

Oops, forgot to paste in the simplified test case that I just promised. Here it is: <?xml version="1.0"?> <?xml-stylesheet href="chrome://global/skin/" type="text/css"?> <?xul-overlay href="chrome://global/content/dialogOverlay.xul"?> <!DOCTYPE window SYSTEM "chrome://global/locale/commonDialog.dtd"> <window xmlns:html="http://www.w3.org/TR/REC-html40" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" align="vertical" onload="commonDialogOnLoad()" class="dialog"> <html:input type="checkbox" id="checkbox" /> </window>

ftp authentication exhibits the same checkbox problem. For users inside netscape, a good test url is ftp://<username>@raquelita. If your outside the firewall, then pick your own favorite site that requires ftp authentication. As a side comment, the related but 27784 (password field cannot be typed into) does not occur with the ftp dialog -- it is an issue with http dialog only. Now here's a surprise that I didn't expect. Both http authentication and ftp authentication exhibit the problem when using the full commonDialog.xul file. But if I replace it with the simplified example shown above, the problem is exhibited in http authentication only -- the checkbox works fine in ftp authentication. !!!!!

Ignore above comment about ftp authentication. I must have been sleeping when I wrote it. Here's the correct observation about ftp authentication. ftp authentication does not exhibit the checkbox problem at all. Neither with the full commonDialog.xul file nor with the stripped-down version. Furthermore, ftp authentication does not exhibit the password-field problem reported in bug 27784.

Just became aware of bug 27717. Very similar to this one. The only difference is that bug 27717 talks about the checkbox in imap password dialog whereas this one is concerned with the http authentication dialog. Well actually this bug talks about both. I suggest we keep this bug for the http problem and leave the other one for the imap problem.

Dan, since you also own bug #27717, I'm assigning this to you. If you shouldn't won this as well, let me know.

FWIW, here's another piece of information. Basically this is proof that items being scheduled by the onclick handler (such as repainting) are not getting performed. I modified the OnCheckboxClick() routine in commonDialog.js as follows: It originally was ----------------- function onCheckboxClick() { param.SetInt( 1, (param.GetInt( 1 ) ? 0 : 1 )); } and I changed it to: function onCheckboxClick() { setTimeout("onCheckboxClick2();",0); dump("leaving onCheckboxClick\n"); } function onCheckboxClick2() { dump("entering onCheckboxClick2\n"); param.SetInt( 1, (param.GetInt( 1 ) ? 0 : 1 )); } The result was that I got the message about leaving the onCheckBoxClick routine but I never entered the onCheckBoxClick2 routine. On my windows box of course I got both messages printed out.

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

reassigning to pavlov to load balance.

Alright, on the auspicious occasion of Peter's balancing this bug off my back and back onto Pav's, I'll spill what little I've figured out. Most of this can be found by poking around in the comments for duplicate bug 27717. By now it's common knowledge that the CPU is pegged while this dialog is up and misbehaving. That's on Linux, only. On NT, the machine load is very low. I've tried summoning the exact same dialog, using PromptUsernameAndPassword as is the case when it misbehaves. That goes through Wallet and nsCommonDialog and all the same UI grief and produces a perfectly well-behaved dialog. The difference between this scenario and the bad one is the way the dialog is being summoned. In the bad case, it's summoned during a network connection which is frozen pending results from the dialog. In both cases the dialog is being called from the primordial thread, so there's no real thread proxy thing happening. Synthesizing this and something morse mentioned above, it seems the problem happens only when necko has frozen a protocol handler and is running a dialog on the same thread. The CPU will unpeg if you inject PR_Sleeps into the modal window captive event loop. But even then the dialog doesn't seem to behave any better. I've been trying to blame this on some bad interaction between something necko does to freeze the connection, nspr's pthreads implementation, and the tight gtk event loop. Haven't really gotten very far with it yet. But I am adding gagan to the spam list. There's my contribution.

I have some code that "fixes" this bug, but it doesn't address the real issue here. The real issue being that the CPU is being pegged when this dialog is up. I have stepped through the code, and thought I had it figured out, but now gdb won't show me this code. ... back to working on it.

The system event notification pipe was not empty, and processing on it was stalled because of the frozen protocol channel. This pegged the CPU, which sounds bad, though it seemed to have no particular consequence other than losing paint events on the affected dialog. Pavlov and I have arranged for the notification pipe to be drained while the dialog is up, and then reinstated. Hurt me.

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

verified 3/3

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