Closed Bug 28241 Opened 25 years ago Closed 25 years ago

both Password and Open Web Location dialogs appear; crash on Windows

Categories

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

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: danm.moz)

References

()

Details

(Keywords: crash, platform-parity, Whiteboard: [PDT+])

i saw this occur using the 2000021708 opt comm bits on linux and winNT. (not a problem on mac.) i experienced a crash only on winNT, tho. not sure if this is a problem with Single Signon or XPApps (opening web location)... recipe: 0. make sure you have (a) a master passwd and (b) already saved username/passwd info at the above URL (you can use any username/passwd, really). 1. start a new session of seamonkey. 2. bring up the Open Web Location dialog (i used the keyboard shortcut of Ctrl+O). 3. copy the above URL exactly and paste it into the input field. 4. hit Open button. observe: you're brought to the above page, and the Password dialog appears --but the Open Web Location dialog doesn't go away. (on linux its content area turns black.) 5. hit the Cancel button in the Open Web Location dialog. results: on NT, it crashes (i've added the Talkback info below). on linux, nothing happens, and i can enter passwd info in the Password dialog and click OK (or Cancel), then both dialogs disappear w/o further problems. http://cyclone/reports/incidenttemplate.CFM?reportID=124&style=0&tc=28&cp=1&ck1=SUser+email+address&cd1=%25sairuh%40netscape%2Ecom%25&co1=like&bbid=5537721 Trigger Type: Program Crash Trigger Reason: Access violation Thread ID: Call Stack: (Signature = nsChromeTreeOwner::SetVisibility ad538ccb) nsChromeTreeOwner::SetVisibility [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsChromeTreeOwner.cpp, line 280] GlobalWindowImpl::Focus [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1212] nsWebShellWindow::HandleEvent [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 540] nsWindow::DispatchEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 497] nsWindow::DispatchWindowEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 514] nsWindow::DispatchFocus [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 3087] nsWindow::ProcessMessage [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 2335] nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 674] USER32.dll + 0x19d0 (0x77e719d0) USER32.dll + 0x1982 (0x77e71982) ntdll.dll + 0x163a3 (0x77f763a3) USER32.dll + 0x18d2 (0x77e718d2) nsWindow::DefaultWindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 700] USER32.dll + 0x27fe (0x77e727fe) USER32.dll + 0x2889 (0x77e72889) nsWindow::WindowProc [d:\builds\seamonkey\mozilla\widget\src\windows\nsWindow.cpp, line 685] USER32.dll + 0x19d0 (0x77e719d0) USER32.dll + 0x1982 (0x77e71982) ntdll.dll + 0x163a3 (0x77f763a3) USER32.dll + 0x1bd8 (0x77e71bd8) nsAppShell::GetNativeEvent [d:\builds\seamonkey\mozilla\widget\src\windows\nsAppShell.cpp, line 159] nsXULWindow::ShowModal [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsXULWindow.cpp, line 897] nsWebShellWindow::ShowModal [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 1126] nsChromeTreeOwner::ShowModal [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsChromeTreeOwner.cpp, line 181] GlobalWindowImpl::OpenInternal [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 2429] GlobalWindowImpl::OpenDialog [d:\builds\seamonkey\mozilla\dom\src\base\nsGlobalWindow.cpp, line 1520] nsCommonDialogs::DoDialog [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsCommonDialogs.cpp, line 428] nsCommonDialogs::UniversalDialog [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsCommonDialogs.cpp, line 229] nsWebShellWindow::UniversalDialog [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsWebShellWindow.cpp, line 2107] nsNetSupportDialog::UniversalDialog [d:\builds\seamonkey\mozilla\xpfe\appshell\src\nsNetSupportDialog.cpp, line 135] wallet_GetString [d:\builds\seamonkey\mozilla\extensions\wallet\src\wallet.cpp, line 923] Wallet_SetKey [d:\builds\seamonkey\mozilla\extensions\wallet\src\wallet.cpp, line 1796] si_SetKey [d:\builds\seamonkey\mozilla\extensions\wallet\src\singsign.cpp, line 327] SI_LoadSignonData [d:\builds\seamonkey\mozilla\extensions\wallet\src\singsign.cpp, line 1788] SINGSIGN_RestoreSignonData [d:\builds\seamonkey\mozilla\extensions\wallet\src\singsign.cpp, line 2417] nsWalletlibService::OnEndDocumentLoad [d:\builds\seamonkey\mozilla\extensions\wallet\src\nsWalletService.cpp, line 314] nsStr::Destroy [d:\builds\seamonkey\mozilla\xpcom\ds\nsStr.cpp, line 87] nsString::~nsString [d:\builds\seamonkey\mozilla\xpcom\ds\nsString2.cpp, line 136] _hashKeyCompare [d:\builds\seamonkey\mozilla\xpcom\ds\nsHashtable.cpp, line 38] PL_HashTableRawLookup [plhash.c, line 190] MSVCRT.dll + 0x136c (0x7800136c) 0x00ee7308 0x0ba51500 js3250.dll + 0x3e2c0 (0x60afe2c0)
nominating for beta1.
Keywords: beta1, crash, pp
Now this is really strange. I just tried the test three times and got three different symptoms. Here they are: 1. Save username/password for this site and exit browser 2. Next session, perform indicated test. Open-web-location dialog did not vanish when password dialog came up. But pressing cancel on password dialog did not cause a crash -- instead both dialogs closed. 3. Next session, perform indicated test. Open-web-location dialog closed when pasword dialog came up. Pressing cancel dismissed password dialog. No crash 3. Next session, perform indicated test. Open-web-location did not vanish when password dialog came up. Pressing cancel in password dialog caused crashed. This matches the symptoms that sairuh reported. The stacktrace at the time of the crash is shown below. From the above I think it's safe to assume that we have some sort of race condition. Also it looks like a modal-dialog issue and not a single-signon issue. Reassigning to danm. nsChromeTreeOwner::SetVisibility(nsChromeTreeOwner * const 0x02cc4a44, int 1) line 279 + 19 bytes GlobalWindowImpl::Focus(GlobalWindowImpl * const 0x02cc66c8) line 1211 nsWebShellWindow::HandleEvent(nsGUIEvent * 0x0012c050) line 540 nsWindow::DispatchEvent(nsWindow * const 0x02cc0bb4, nsGUIEvent * 0x0012c050, nsEventStatus & nsEventStatus_eIgnore) line 493 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012c050) line 514 nsWindow::DispatchFocus(unsigned int 104) line 3086 + 15 bytes nsWindow::ProcessMessage(unsigned int 7, unsigned int 29362080, long 0, long * 0x0012c2a4) line 2334 + 19 bytes nsWindow::WindowProc(HWND__ * 0x0374066e, unsigned int 7, unsigned int 29362080, long 0) line 673 + 27 bytes USER32! 77e7131f() USER32! 77e71a3d() NTDLL! 77f7637b() USER32! 77e7136c() nsWindow::DefaultWindowProc(HWND__ * 0x0374066e, unsigned int 6, unsigned int 1, long 6948746) line 700 USER32! 77e72ba5() USER32! 77e72b78() nsWindow::WindowProc(HWND__ * 0x0374066e, unsigned int 6, unsigned int 1, long 6948746) line 680 + 31 bytes USER32! 77e7131f() USER32! 77e71a3d() NTDLL! 77f7637b() nsWindow::~nsWindow() line 322 nsWindow::`scalar deleting destructor'() + 15 bytes nsWindow::Release(nsWindow * const 0x03026d54) line 222 + 147 bytes nsCOMPtr<nsIWidget>::~nsCOMPtr<nsIWidget>() line 435 nsXULWindow::ShowModal(nsXULWindow * const 0x03026e70) line 916 + 31 bytes nsWebShellWindow::ShowModal(nsWebShellWindow * const 0x03026e70) line 1125 + 9 bytes nsChromeTreeOwner::ShowModal(nsChromeTreeOwner * const 0x03026230) line 181 GlobalWindowImpl::OpenInternal(GlobalWindowImpl * const 0x0201b450, JSContext * 0x0201b2c0, long * 0x02275f20, unsigned int 4, int 1, nsIDOMWindow * * 0x0012ca2c) line 2429 GlobalWindowImpl::OpenDialog(GlobalWindowImpl * const 0x0201b458, JSContext * 0x0201b2c0, long * 0x02275f20, unsigned int 4, nsIDOMWindow * * 0x0012ca2c) line 1520 nsCommonDialogs::DoDialog(nsCommonDialogs * const 0x03013f20, nsIDOMWindow * 0x0201b458, nsIDialogParamBlock * 0x03012ba0, const char * 0x01176514) line 421 + 29 bytes nsCommonDialogs::UniversalDialog(nsCommonDialogs * const 0x03013f20, nsIDOMWindow * 0x0201b458, const unsigned short * 0x00000000, const unsigned short * 0x03011170, const unsigned short * 0x030106c0, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, ...) lin nsWebShellWindow::UniversalDialog(nsWebShellWindow * const 0x018c2f7c, const unsigned short * 0x00000000, const unsigned short * 0x03011170, const unsigned short * 0x030106c0, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * ...) line nsNetSupportDialog::UniversalDialog(nsNetSupportDialog * const 0x030113c0, const unsigned short * 0x00000000, const unsigned short * 0x03011170, const unsigned short * 0x030106c0, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * ...) l wallet_GetString(nsAutoString & {""}, unsigned short * 0x030106c0, unsigned short * 0x03011670) line 921 + 84 bytes Wallet_SetKey(int 0) line 1794 + 26 bytes si_SetKey() line 326 + 7 bytes SI_LoadSignonData(int 1) line 1787 + 5 bytes SINGSIGN_RestoreSignonData(char * 0x02c71650, unsigned short * 0x02c71030, unsigned short * * 0x0012d54c, unsigned int 0) line 2416 + 7 bytes nsWalletlibService::OnEndDocumentLoad(nsWalletlibService * const 0x0212e66c, nsIDocumentLoader * 0x02a9e4c0, nsIChannel * 0x02e071d0, unsigned int 0) line 313 + 48 bytes nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x02a9e4c0, nsIChannel * 0x02e071d0, unsigned int 0) line 603 nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x02a9e4c0, nsIChannel * 0x02e071d0, unsigned int 0) line 611 nsDocLoaderImpl::FireOnEndDocumentLoad(nsDocLoaderImpl * 0x02a9e4c0, nsIChannel * 0x02e071d0, unsigned int 0) line 611 nsDocLoaderImpl::DocLoaderIsEmpty(unsigned int 0) line 494 nsDocLoaderImpl::OnStopRequest(nsDocLoaderImpl * const 0x02a9e4c4, nsIChannel * 0x02e071d0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 438 nsLoadGroup::RemoveChannel(nsLoadGroup * const 0x02a9e460, nsIChannel * 0x02e071d0, nsISupports * 0x00000000, unsigned int 0, const unsigned short * 0x00000000) line 535 + 42 bytes nsHTTPChannel::ResponseCompleted(nsIChannel * 0x02bccc74, nsIStreamListener * 0x02c32f90, unsigned int 0, const unsigned short * 0x00000000) line 1344 nsHTTPResponseListener::OnStopRequest(nsHTTPResponseListener * const 0x02da60e0, nsIChannel * 0x02bccc74, nsISupports * 0x02e071d0, unsigned int 0, const unsigned short * 0x00000000) line 255 nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x02aed040) line 279 nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x02aed270) line 93 + 12 bytes PL_HandleEvent(PLEvent * 0x02aed270) line 526 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x02cc2700) line 487 + 9 bytes _md_EventReceiverProc(HWND__ * 0x006506a2, unsigned int 49378, unsigned int 0, long 46933760) line 975 + 9 bytes USER32! 77e71268() 005a0112()
Assignee: morse → danm
I decided to see if I could eliminate single-signon from the equation completely. If it is a dialog problem, then it should be reproducible with any dialog that appears when a page is loaded -- for example the cookie nag box. So I used the open dialog to get to netcenter. No problem. The open dialog vanished and then a short time later the cookie nag box appeared. I tried a few other sites and they all worked fine. Then I returned to netcenter. This time the open dialog did not vanish when the cookie nag box appeared. So it definitely is a race condition. Specifically, the cookie nag box (and the single signon dialog) occur after the page finishes loading. So it depends on how fast the server can respond with the page. Also it helps if the page is already in the cache. If the page finishes loading before the browser had a chance to take down the open dialog, we get the problem. My guess is that the commondialog code is not reentrant. But that's just a guess -- I have no hard facts to base that on.
Scratch what I said way above about this being a modal dialog issue. From my later analysis I see that it has nothing to do with whether the dialog is modal or not. The problem is instead a race condition.
PDT+
Whiteboard: [PDT+]
Target Milestone: M14
Severity: major → critical
Whiteboard: [PDT+] → [PDT+] yeesh. date unknown.
might this be related to bug 27784 in any way? just curious...
Will become pdt- on 02/25 if no fix landed.
Whiteboard: [PDT+] yeesh. date unknown. → [PDT+] Must fix 02/25 - yeesh. date unknown.
Whiteboard: [PDT+] Must fix 02/25 - yeesh. date unknown. → [PDT+] yeesh. date unknown.
I don't see any relation to bug 27784. That one has to do with entering text in authentication dialogs. This has to do with concurrent dialogs.
A modal window can't completely delete itself while a more recent modal window has Mozilla's attention. The solution was simply to protect it from spurious messages by hiding it until has a chance to catch up.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] yeesh. date unknown. → [PDT+]
verif on linux and winNT, opt comm bits 2000022808.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.