If you have created a non-blank password, you can not recall signons on Linux and in fact you are in effect 'locked out' of your browser. To reproduce: 1. Goto slip/projects/marvin/wallet/login.html 2. Press OK when asked if you want to save sign-on 3. Enter a non-blank password when asked 4. Shutdown 5. Go back to slip/projects/marvin/wallet/login.html Results: Empty Password Dialogue screen comes up. The login.html page lays out behind the window but you can not access it. I suspect there is some kind of ordering problem - on Windows the login.html does not lay out until you enter your password. Also, the empty Password Dialogue Screen cannot be closed, and since it is a modal dialogue, you can't browse anymore. You can close the browser with X however, and re-start. If you have a blank password, or have already opened your database when submitting a form earlier in your session, then you can recall your signon, as you are not asked for a password. This is using 6/18 builds. I can not test on Mac since I can't enter passwords, but this works OK on Windows.

Just want to clarify the symptoms. There are several possible times when the password dialog box can appear: 1. When you submit a form 2. When you press the quickfill or safefill menu button 3. When a form is being received from the server From what you are describing, it sounds like (1) and (2) might be working fine and that (3) is failing. Can you verify that this is the case. Here is how you can get the three cases (note that you must restart the browser before each case): 1. Either submit a password form containing a username that has not previously been saved, or submit one of the sample forms found in edit/wallet/samples 2. Do quickfill or safefill from any of the forms in edit/wallet/samples. 3. Go to a url containing a login form for which data has already been saved. If indeed (3) is the only case that is failing, then this might be a threading problem because that dialog could be coming on the netlib thread. Please let me know if (3) is the only failure case and that (1) and (2) never fail.

You are correct. 3) is the only problem.

Thanks, Paul. That convinces me that it is a netlib threading problem and things might be altogether different when necko lands. So I'll wait until after then before looking into this bug.

Marking as M9 since this depends on necko.

This bug is not just linux as indicated by bug 9259 (which I am about to mark as a duplicate of this one). So I am removing the Linux from the Summary line and from the OS field.

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

Changing summary line to be more indicative of what the bug acually is.

removing PP (platform parity) as yes, it occurs on Windows now also. Since this is marked M9, I will open a new bug to have single-signon disabled (or something similar) for M8

So that's what PP stands for! Please don't open a bug saying that single-singon needs to be disabled because the problem is deeper than that. In fact, see bug 9041 (which may even be a duplicate of this one but I'm not prepared to mark them as such just yet). In that bug report I mention that the problem occurs whenever you go to a site that requires authentication. That has nothing to do with single-singon and turning off single-singon will not solve the problem at such sites. The ONLY way to fix the problem is to fix dialogs that occur on the netlib thread. But that won't happen until necko lands.

OK, you already opened the bug report like you said you would. That new report number is 9326. So I fixed the really bad part (i.e., not being able to close this pop-up once it occurs) and consequently was able to close out bug report 9326. The fact that this pop-up occurs at all is some regression that someone introduced probably into the threading model. But Warren promises that all this will be fixed when necko lands so this will remain as an M9 bug. There is a work-around. The dialog that is occuring is because single-signon is attempting to open the database of your saved logins and it needs to prompt you for your password to unlock that database. If you unlock that database yourself before getting to the login form that needs it, you won't get this prompt and all will be fine. To unlock the data base manually, go to the menu item edit/wallet/wallet-contents. Having done this once at the beginning of your browser session will prevent this empty dialog from occuring later in the session.

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

you can also change your password to blank using the Edit - Wallet - Change Password menu.

This bug, which was a regression to start with, has suddently regressed much further. Now every dialog is coming up blank, whether it is called from the netlib thread or not. In particular, the work-arounds described above (edit/wallet/change-password or edit/wallet/wallet-contents) do not work any more because the dialogs in those cases are coming up blank. Also the dialog asking if you want to save when you submit a form as well as when you log on to a site are both coming up blank. Consequently all wallet and single signon is now completely busted!!!!!! Paulmac, can you determine as to when these new symtpoms started to occur? I.e., as of which build were these additional dialogs still working? Does this new problem occur in the M8 release?

This bug, which was a regression to start with, has suddently regressed much further. Now every dialog is coming up blank, whether it is called from the netlib thread or not. In particular, the work-arounds described above (edit/wallet/change-password or edit/wallet/wallet-contents) do not work any more because the dialogs in those cases are coming up blank. Also the dialog asking if you want to save when you submit a form as well as when you log on to a site are both coming up blank. Consequently all wallet and single signon is now completely busted!!!!!! Paulmac, can you determine as to when these new symtpoms started to occur? I.e., as of which build were these additional dialogs still working? Does this new problem occur in the M8 release?

Since this is now occuring on all threads, removing the "on netlib thread" phrase from the summary line.

The problem does not occur in M8 builds, fortunately. The problem does, however, occur in the first M9 build which came out Tuesday evening, so the bug must have been introduced before then. Note: QA hasn't started tested M9 builds yet.

I'm seeing it in m9 as well. (windows and linux.) adding myself to the cc list so I'll know when it gets fixed.

not in the wallet code, I should have added. also, I'm using the PromptPassword() method. I haven't tried Alert().

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

OK, I have a fix for the latest regression (thanks to Andreas Otte) and will check it in as soon as the tree goes green. Problem is that all the dialog xul files were moved from resource:/res/samples to resource:/chrome/navigator/content/default but this was never updated in nsNetSupportDialog.cpp. This solves the latest regression but not the original ones. Namely, dialogs that are coming up on the layout thread (previously I mistakenly referred to that as the netlib thread) are still coming up blank. So this report will remain open even after I checkin the corrected nsNetSupportDialog.cpp.

Matt was saying something about chrome: being the right target place

marking this as a blocker. I will look at this when the next necko builds come out.

Paul, please tell me what you are doing to observe this under necko. I attempted to try this out as soon as I got my first necko build, but too many other necko bugs prevented me from doing so. Give me a scenario under necko that demonstrates the problem. Thanks.

I have not tested this yet with necko as I am awaiting a release build that will launch on my machine. I marked it as a blocker based on it's behavior with non-necko builds.

With a change that Neeti is about to check in to nsAppRunner.cpp, I am now able to test this out under necko. And, unfortunately, it doesn't work. So much for necko solving all the worlds problems. The test that I did was to get to a page that contained a login form for which I had previously saved the username/password. That previous run was done using a non-necko build because of problems that I was having submitting a form under necko. I simply copied the signon.* files from the old tree. What I observe now is that a dialog box came up but it was blank. Just like it used to be in non=necko prior to my putting in the band-aid hack described in bug 9326.

Mail message I sent out today summarizing this problem: I've been deluding myself into believing that necko was going to solve all our problems and that dialog problems due to threading would all go away. And in a conversation that I had with Rick Potts about that a while back, he told me that necko does not put up any dialogs on its own thread but rather switches to the protocol handlers which run on the UI thread. So that would imply that dialogs should work fine once necko lands. Well that's not what happened. In my necko build I am still having problems with certain dialogs coming up blank. This is reported in bug 8511. In particular, I have two scenarios, one in which the dialog comes up fine and one in which it does not. #1: Good case -- dialog works fine: Enter browser and do edit/wallet/wallet-contents. A dialog appears asking for the key to unlock the wallet database. The dialog is filled in properly (except for the fact that the text is slightly truncated but that is a separate issue -- namely bug 10423). #2: Bad case -- dialog come up empty: Enter browser and go to a page which contains a login form (scopus.mcom.com/bugsplat is a good example). Fill in username/password and log in. Answer yes to the question about saving the data. Exit browser. Reenter browser and go back to the same login form. A dialog appears asking for the key to unlock the wallet database. Except this dialog is transparent -- nothing is in it except what happened to be on the screen at that position before the dialog came up. I stopped the browser while the dialog was being displayed in each of the two cases. I don't know enough about threading to determine which thread we are on in each case. But both traces start off the same (does that mean they are on the same thread?) and then start to differ as we go up the thread -- in the good case it goes through some javascript routines before getting to my code and in the bad case it doesn't. I don't know what significance that has. Below are the two stack traces. What does all this mean? What must we do in order to get dialogs to work now that we have necko? And who should own this problem? BTW, this particular bad case is a regression that started a few weeks ago. Prior to that time the bad-case dialog was working fine. Nothing changed in this area of wallet so the regression is most likely due to some recent change external to wallet. GOOD CASE: USER32! 77e720c1() nsAppShell::GetNativeEvent(nsAppShell * const 0x0a9e5f00, int & 1, void * & 0x010c6c70 msg) line 82 + 17 bytes nsWebShellWindow::ShowModalInternal(nsWebShellWindow * const 0x0a9e3f40) line 1644 + 20 bytes nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x0a9e3f40) line 1616 + 9 bytes nsAppShellService::RunModalDialog(nsAppShellService * const 0x00ab5240, nsIWebShellWindow * * 0x0012bc08, nsIURI * 0x0a9e42e0, nsIWebShellWindow * 0x00000000, nsIStreamObserver * 0x00000000, nsIXULWindowCallbacks * 0x0a9e4614, int 300, int 200) line 717 nsNetSupportDialog::DoDialog(nsString & {...}) line 531 nsNetSupportDialog::PromptPassword(nsNetSupportDialog * const 0x0a9e4610, const unsigned short * 0x0a9e44e0, unsigned short * * 0x0012bd00, int * 0x0012bd20) line 462 wallet_GetString(char * 0x0a9e4050) line 580 + 30 bytes Wallet_SetKey(int 0) line 899 + 9 bytes wallet_Initialize() line 1637 + 7 bytes WLLT_PreEdit(nsAutoString & {...}) line 2176 nsWalletlibService::WALLET_PreEdit(nsWalletlibService * const 0x00b19b90, nsAutoString & {...}) line 99 + 9 bytes WalletEditorImpl::GetValue(WalletEditorImpl * const 0x0a8c72b0, char * * 0x0012c05c) line 90 + 16 bytes XPTC_InvokeByIndex(nsISupports * 0x0a8c72b0, unsigned int 4, unsigned int 1, nsXPTCVariant * 0x0012c05c) line 135 nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x0a1dbc20, nsXPCWrappedNative * 0x0a8c8ea0, const XPCNativeMemberDescriptor * 0x0a8c8f18, nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 0, long * 0x09e94e50, long * 0x0012c264) line 511 + 44 bytes WrappedNative_CallMethod(JSContext * 0x0a1dbc20, JSObject * 0x00cfb550, unsigned int 0, long * 0x09e94e50, long * 0x0012c264) line 130 js_Invoke(JSContext * 0x0a1dbc20, unsigned int 0, unsigned int 0) line 654 + 26 bytes js_Interpret(JSContext * 0x0a1dbc20, long * 0x0012ca8c) line 2228 + 15 bytes js_Invoke(JSContext * 0x0a1dbc20, unsigned int 0, unsigned int 0) line 670 + 13 bytes js_Interpret(JSContext * 0x0a1dbc20, long * 0x0012d270) line 2228 + 15 bytes js_Invoke(JSContext * 0x0a1dbc20, unsigned int 0, unsigned int 0) line 670 + 13 bytes js_Interpret(JSContext * 0x0a1dbc20, long * 0x0012da54) line 2228 + 15 bytes js_Invoke(JSContext * 0x0a1dbc20, unsigned int 0, unsigned int 0) line 670 + 13 bytes js_Interpret(JSContext * 0x0a1dbc20, long * 0x0012e238) line 2228 + 15 bytes js_Invoke(JSContext * 0x0a1dbc20, unsigned int 1, unsigned int 2) line 670 + 13 bytes js_InternalCall(JSContext * 0x0a1dbc20, JSObject * 0x00d05788, long 13612432, unsigned int 1, long * 0x0012e378, long * 0x0012e380) line 747 + 15 bytes JS_CallFunctionValue(JSContext * 0x0a1dbc20, JSObject * 0x00d05788, long 13612432, unsigned int 1, long * 0x0012e378, long * 0x0012e380) line 2643 + 29 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x0a9bc4f0) line 97 + 34 bytes nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent * 0x0012e534, nsIDOMEvent * * 0x0012e49c, unsigned int 3, nsEventStatus & nsEventStatus_eIgnore) line 959 + 21 bytes GlobalWindowImpl::HandleDOMEvent(GlobalWindowImpl * const 0x0a1db1a4, nsIPresContext & {...}, nsEvent * 0x0012e534, nsIDOMEvent * * 0x0012e49c, unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 2744 nsWebShell::OnEndDocumentLoad(nsWebShell * const 0x0a2ac4f4, nsIDocumentLoader * 0x0a2ac480, nsIChannel * 0x0a2ad700, int 0, nsIDocumentLoaderObserver * 0x0a2ac4f4) line 2963 + 34 bytes nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x0a2ac480, int 0) line 1100 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x0a2ac484, nsIChannel * 0x0a2ad700, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 1025 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x0a9bc3e0) line 284 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0a9bc3e4) line 149 + 12 bytes PL_HandleEvent(PLEvent * 0x0a9bc3e4) line 509 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ab5540) line 470 + 9 bytes _md_EventReceiverProc(HWND__ * 0x1c6c026a, unsigned int 49387, unsigned int 0, long 11228480) line 932 + 9 bytes USER32! 77e71268() BAD CASE: USER32! 77e720c1() nsAppShell::GetNativeEvent(nsAppShell * const 0x0a285040, int & 1, void * & 0x010c6c70 msg) line 82 + 17 bytes nsWebShellWindow::ShowModalInternal(nsWebShellWindow * const 0x0a283ef0) line 1644 + 20 bytes nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x0a283ef0) line 1616 + 9 bytes nsAppShellService::RunModalDialog(nsAppShellService * const 0x00ab5240, nsIWebShellWindow * * 0x0012d698, nsIURI * 0x0a280bb0, nsIWebShellWindow * 0x00000000, nsIStreamObserver * 0x00000000, nsIXULWindowCallbacks * 0x0a280654, int 300, int 200) line 717 nsNetSupportDialog::DoDialog(nsString & {...}) line 531 nsNetSupportDialog::PromptPassword(nsNetSupportDialog * const 0x0a280650, const unsigned short * 0x0a283730, unsigned short * * 0x0012d790, int * 0x0012d7b0) line 462 wallet_GetString(char * 0x0a280470) line 580 + 30 bytes Wallet_SetKey(int 0) line 899 + 9 bytes si_SetKey() line 413 + 7 bytes SI_LoadSignonData(int 1) line 1853 + 5 bytes SINGSIGN_RestoreSignonData(char * 0x0a231ef0, char * 0x0a230390, char * * 0x0012fb98) line 2484 + 7 bytes nsWalletlibService::OnEndDocumentLoad(nsWalletlibService * const 0x00b1997c, nsIDocumentLoader * 0x09e0ff60, nsIChannel * 0x00000000, int 0, nsIDocumentLoaderObserver * 0x00b1997c) line 351 + 23 bytes nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x09e0ff60, int 0) line 1100 nsDocLoaderImpl::ChildDocLoaderFiredEndDocumentLoad(nsDocLoaderImpl * 0x00b17820, nsIDocumentLoader * 0x09e0ff60, int 0) line 1123 nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x09e0ff60, int 0) line 1108 nsDocLoaderImpl::ChildDocLoaderFiredEndDocumentLoad(nsDocLoaderImpl * 0x09ceb4b0, nsIDocumentLoader * 0x09e0ff60, int 0) line 1123 nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x09e0ff60, int 0) line 1108 nsDocLoaderImpl::ChildDocLoaderFiredEndDocumentLoad(nsDocLoaderImpl * 0x09e0ff60, nsIDocumentLoader * 0x09e0ff60, int 0) line 1123 nsDocLoaderImpl::FireOnEndDocumentLoad(nsIDocumentLoader * 0x09e0ff60, int 0) line 1108 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x09e0ff64, nsIChannel * 0x0a2361f0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 1025 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x0a27d390) line 284 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0a27d394) line 149 + 12 bytes PL_HandleEvent(PLEvent * 0x0a27d394) line 509 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00ab5540) line 470 + 9 bytes _md_EventReceiverProc(HWND__ * 0x017e0252, unsigned int 49387, unsigned int 0, long 11228480) line 932 + 9 bytes USER32! 77e71268() 00ab5540()

Message received from hyatt today: I see the problem. No pushing/popping of queues is happening down this code path. Dan and i can fix it, but it needs some thought. So I'm reassigning bug to hyatt.

Further messages from hyatt: From the stack trace, it looks to me like this scenario would never have worked under Netlib either. The problem is basically just that the push needs to happen earlier. We have code that looks something like this... 1. Event comes in on outer queue. We start processing it and determine we need to make a dialog. 2. Create dialog window (which kicks off the chrome load using the outer queue, uh-oh). 3. Push a queue. 4. Enter a modal loop. 5. Pop a queue. The problem is that 3 needed to happen before 2. All of the queues involved in the chrome loading are using the wrong queue (the outer queue), and so we never process any of the events for the chrome load. I think we can just rework it so that there's a one-shot make-and-show-the-modal-dialog function, and then this problem will be solved. In that function, we can push right up front, and then we'll be ok. *************************** dan tells me that if we do this, bug #7858 will become an issue again, so if we do this, the pressure will be on joki to solve this.

Can someone give me an estimate as to when this bug will get fixed. It is blocking a the development and testing of single signon.

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

By the way, this has been hacked to work without breaking bug 7858, as threatened above. It only works on Windows and the Mac right now, however. Leaving open.

Dan, did you check in your fix that works on Mac/Windows? I actually still see this on Windows.

This was working Mac and Windows last time I checked. Sigh. Would love to get to this by M9, but ain't happening.

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

This bug has gotten unwieldly. Am creating a new bug report and marking this bug as a dup of the new one. *** This bug has been marked as a duplicate of 12137 ***