Closed
Bug 52664
Opened 24 years ago
Closed 24 years ago
crash after closing dialog box
Categories
(Core :: Networking, defect, P3)
Tracking
()
People
(Reporter: uamjet602, Assigned: gagan)
References
()
Details
(Keywords: crash, Whiteboard: [nsbeta3-][rtm+])
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m18) Gecko/20000914
BuildID: 2000091408
When trying to login, if you don't enter a correct name and pass, you get a
dialog box telling you to try again. When you dismiss the dialog, Mozilla crashes
Reproducible: Always
Steps to Reproduce:
1.Go to the URL
2.Fill in some random username and password
3.When you get the dialog box, dismiss it.
Actual Results: Mozilla crashes
Expected Results: Return to the page.
This does not happen on Windows 2000 and Win32. People in the #mozillazine
channel told me this might be related to bug no. 51619. I tried to make a stack
trace but failed as gdb crashed.
Comment 1•24 years ago
|
||
Reproducible with the 091408 linux build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 3•24 years ago
|
||
Does this occur on any top100 sites? Can we get a common reproducible case?
Whiteboard: [need info]
Comment 4•24 years ago
|
||
This crash comes down to this condition. The page submits your username and
password by putting them into the query string and doing a location.href
redirect to a cgi-bin that processes the values. If the username/password are
bogus, the document returned fires up an alert() during the page load. When
you cancel out of that alert, you crash.
Here's a simple testcase, also available at
http://jrgm.mcom.com/bugs/52664/login.html
--- login.html ---
<html>
<head>
<script>
function doIt() {
loc = 'response.html';
window.location.href = loc;
return false;
}
</script>
</head>
<body>
<a href="javascript:void()" onClick="return doIt();">Click me and die!</A>
</body>
</html>
--- response.html ---
<html>
<head>
<script>
alert("On linux (and mac in some cases), when you dismiss this alert, you
will crash.");
</script>
</head>
<body>
</body>
</html>
----------------------
Although, I think it really comes down to just loading a page that immediately
fires an alert -- try loading http://jrgm.mcom.com/bugs/52664/response.html,
which also crashes (on Linux, and on Mac if you do a reload of the page). (win32
does not crash under any of these situations). [2000091508].
The stacks are necko code (no window or JS code in the crashes), so
reassigning to gagan/necko.
Nom. nsbeta3 with mixed feelings. Firing an alert while a page is loading is not
disallowed (although it is bad UE design) and we should really try to close off
any crasher. On the other hand, I doubt that firing an alert during a page load
is particularly common (not likely top100).
Assignee: danm → gagan
Component: XP Toolkit/Widgets → Networking
Keywords: nsbeta3
QA Contact: jrgm → tever
Whiteboard: [need info]
Well, at least you will know upfront what will be the most prominent features of
the next release of FrontPage if you leave bugs like this one in.
Also on the other hand if IE had something like this it would be called a DOS
attack.
Just my 2 cents, feel free to not take offense please.
Comment 6•24 years ago
|
||
Here is a Linux stack trace I got after running John's testcase above:
http://jrgm.mcom.com/bugs/52664/login.html
#0 0x3 in ?? ()
#1 0x40a00a68 in nsHTTPCacheListener::OnDataAvailable (this=0x8781190,
aChannel=0x85bc2d0, aContext=0x0, aStream=0x8800058,
aSourceOffset=0, aCount=137) at nsHTTPResponseListener.cpp:191
#2 0x409d9f62 in nsDiskCacheRecordChannel::OnDataAvailable (this=0x85bc2d0,
transportChannel=0x859f6a0, context=0x0,
aIStream=0x8800058, aSourceOffset=0, aLength=137) at
nsDiskCacheRecordChannel.cpp:727
#3 0x40996e2f in nsOnDataAvailableEvent::HandleEvent (this=0x87fd738) at
nsAsyncStreamListener.cpp:400
#4 0x409960b7 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x87fd760) at
nsAsyncStreamListener.cpp:97
#5 0x401244be in PL_HandleEvent (self=0x87fd760) at plevent.c:575
#6 0x401242dc in PL_ProcessPendingEvents (self=0x80aa328) at plevent.c:508
#7 0x40126129 in nsEventQueueImpl::ProcessPendingEvents (this=0x80aa300) at
nsEventQueue.cpp:356
#8 0x40c5da74 in event_processor_callback (data=0x80aa300, source=8,
condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#9 0x40c5d6af in our_gdk_io_invoke (source=0x8163130, condition=G_IO_IN,
data=0x828ed98) at nsAppShell.cpp:58
#10 0x40e2452a in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#11 0x40e25be6 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#12 0x40e261a1 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#13 0x40e26341 in g_main_run () from /usr/lib/libglib-1.2.so.0
#14 0x40d50209 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#15 0x40c5e16a in nsAppShell::Run (this=0x80afa10) at nsAppShell.cpp:335
#16 0x40745164 in nsAppShellService::Run (this=0x8109288) at
nsAppShellService.cpp:407
#17 0x805576f in main1 (argc=1, argv=0xbffffb54, nativeApp=0x0) at
nsAppRunner.cpp:958
#18 0x8055e3e in main (argc=1, argv=0xbffffb54) at nsAppRunner.cpp:1139
Comment 7•24 years ago
|
||
Here is a Linux stack trace I got after running John's other testcase above:
http://jrgm.mcom.com/bugs/52664/response.html
#0 0x4184b723 in nsCOMPtr<nsINameSpaceManager>::assign_with_AddRef
(this=0x8537f60, rawPtr=0x869eaf8)
at ../../../dist/include/nsCOMPtr.h:847
#1 0x4184b75f in nsCOMPtr<nsINameSpaceManager>::operator= (this=0x8537f60,
rhs=0x869eaf8) at ../../../dist/include/nsCOMPtr.h:583
#2 0x4177840f in nsNodeInfoManager::Init (this=0x8537f50,
aNameSpaceManager=0x869eaf8) at nsNodeInfoManager.cpp:109
#3 0x409f6309 in nsHTTPChannel::ReportProgress (this=0x869eaf8,
aProgress=141286701, aProgressMax=141286552)
at nsHTTPChannel.cpp:1602
#4 0x40a00a9a in nsHTTPCacheListener::OnDataAvailable (this=0x86bdcb0,
aChannel=0x86772f0, aContext=0x0, aStream=0x8606e98,
aSourceOffset=0, aCount=137) at nsHTTPResponseListener.cpp:198
#5 0x409d9f62 in nsDiskCacheRecordChannel::OnDataAvailable (this=0x86772f0,
transportChannel=0x881be20, context=0x0,
aIStream=0x8606e98, aSourceOffset=0, aLength=137) at
nsDiskCacheRecordChannel.cpp:727
#6 0x40996e2f in nsOnDataAvailableEvent::HandleEvent (this=0x88331d8) at
nsAsyncStreamListener.cpp:400
#7 0x409960b7 in nsStreamListenerEvent::HandlePLEvent (aEvent=0x8833200) at
nsAsyncStreamListener.cpp:97
#8 0x401244be in PL_HandleEvent (self=0x8833200) at plevent.c:575
#9 0x401242dc in PL_ProcessPendingEvents (self=0x80aa328) at plevent.c:508
#10 0x40126129 in nsEventQueueImpl::ProcessPendingEvents (this=0x80aa300) at
nsEventQueue.cpp:356
#11 0x40c5da74 in event_processor_callback (data=0x80aa300, source=8,
condition=GDK_INPUT_READ) at nsAppShell.cpp:158
#12 0x40c5d6af in our_gdk_io_invoke (source=0x82226e8, condition=G_IO_IN,
data=0x832a058) at nsAppShell.cpp:58
#13 0x40e2452a in g_io_unix_dispatch () from /usr/lib/libglib-1.2.so.0
#14 0x40e25be6 in g_main_dispatch () from /usr/lib/libglib-1.2.so.0
#15 0x40e261a1 in g_main_iterate () from /usr/lib/libglib-1.2.so.0
#16 0x40e26341 in g_main_run () from /usr/lib/libglib-1.2.so.0
#17 0x40d50209 in gtk_main () from /usr/lib/libgtk-1.2.so.0
#18 0x40c5e16a in nsAppShell::Run (this=0x80afa10) at nsAppShell.cpp:335
#19 0x40745164 in nsAppShellService::Run (this=0x8109288) at
nsAppShellService.cpp:407
#20 0x805576f in main1 (argc=1, argv=0xbffffb54, nativeApp=0x0) at
nsAppRunner.cpp:958
#21 0x8055e3e in main (argc=1, argv=0xbffffb54) at nsAppRunner.cpp:1139
Comment 8•24 years ago
|
||
(I was using Mozilla debug tip build 2000-09-18 on Linux)
Comment 10•24 years ago
|
||
per PDT: P3-P5 priority bugs changed from nsbeta3+ to nsbeta3- since we have
more important work to do for Seamonkey. If you disagree, please state your case
in the bug report and nominate for rtm and adjust priority if this bug was
mis-prioritized. Thanks.
Gagan, what do you think?
Whiteboard: [nsbeta3+] → [nsbeta3-]
Comment 11•24 years ago
|
||
This is the same stack trace as bug 53148, now that I look at it. It is a
slightly different testcase, in that this is popping up a modal dialog while
loading (which would effect the event loop), but the crash is in the same
place.
Could be taken as a dup, but adding rtm nomination to both these bugs,
particularly since 53148 is not an uncommon use case with a highly
reproducible crash.
Keywords: rtm
Assignee | ||
Comment 12•24 years ago
|
||
agree with pdt. but making this an rtm+
Whiteboard: [nsbeta3-] → [nsbeta3-][rtm+]
Comment 13•24 years ago
|
||
PDT marking dup
*** This bug has been marked as a duplicate of 53148 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•