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)
Tracking
(Not tracked)
VERIFIED
FIXED
M14
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)
Reporter | ||
Comment 1•25 years ago
|
||
nominating for beta1.
Comment 2•25 years ago
|
||
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
Comment 3•25 years ago
|
||
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.
Comment 4•25 years ago
|
||
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.
Updated•25 years ago
|
Severity: major → critical
Will become pdt- on 02/25 if no fix landed.
Whiteboard: [PDT+] yeesh. date unknown. → [PDT+] Must fix 02/25 - yeesh. date unknown.
Updated•25 years ago
|
Whiteboard: [PDT+] Must fix 02/25 - yeesh. date unknown. → [PDT+] yeesh. date unknown.
Comment 8•25 years ago
|
||
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+]
Reporter | ||
Comment 10•25 years ago
|
||
verif on linux and winNT, opt comm bits 2000022808.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•