Closed Bug 57514 Opened 23 years ago Closed 23 years ago

crash closing double alert from text box 'onchange' event

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: wcd, Assigned: danm.moz)

References

(
URL
)

Details

(Keywords: crash, Whiteboard: [rtm++])

Attachments

(1 file)

above testcase
527 bytes, text/html
Details 
The 'onchange' event of a FORM text box creates two ALERT messages, one behind 
the other, when <cr> is entered after text. If you click and move the top one 
the second one will be revealed. If you click <OK> on the copy that was hiding 
behind the one you moved and then <OK> on the copy you moved NS6b3 will cause a 
memory exception error. If you reverse the order of clicking <OK> another 
problem is caused which I have reported separately.

A test harness with instructions that will consistently reproduce this bug can 
be found at the URL indicated. The code structure that reproduces this problem 
and a problem with the behaviour of FORM events which I will report separately 
follows.

<html>
<head>
<SCRIPT type="text/javascript">
<!--
var _S = 1;
function Submit()
{
 alert("SUBMIT = " + _S);
 _S++;
 return false;
}
var _C = 1;
function Change()
{
 alert("CHANGE = " + _C);
 _C++
}
// -->
</SCRIPT>
</head>
<body>

<form method="POST" action="javascript: alert('ACTION');" onsubmit="return 
Submit();">
   <p><input type="text" name="T1" size="20" onchange="Change();">
   <input type="submit" value="Submit" name="B1">
   </p>
</form>
</body>
</html>
Associated bug reported under #57515
This is   not a 'Java API' Problem

It is a COre DOM (JavaScript) problem 
Changing COmponent to DOM
Component: Java APIs for DOM → DOM Level 0
confirming.
cc-ing danm in case the problem has to do with popup modal windows.
cc-ing pollmann because it's related to forms.
Assignee: akhil.arora → jst
Severity: major → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: crash
Priority: P3 → P1
QA Contact: rajendra.pallath → desale
Attached file above testcase — 

    
    

    
  
See bug 48064 - this bug may be related / a duplicate

    
    

    
  
Don't think it is a duplicate because this bug has two manifestations depending 
on the order your click the <OK> button in the JScripted Alert box. This one 
crashes the system, the second (57515) is just plain obnoxious.

The bug report you refer to seems to be surrounding FORM submission issues. 
Whilst the underlying cause may be the same the conditions which reveal the 
problem appear to be different.

    
    

    
  
Dan, from reading your comment in bug 48064 it looks like you know what's going
on here, reassigning to you :-)
Assignee: jst → danm

    
    

    
  
  The dual alert problem is pretty much straight out of bug 48064, as I've noted 
in that bug report. The crash this causes is a different matter. It happens 
because the second alert is brought up while the first alert is still being 
loaded (see my comment today in bug 48064). And if you close them out of order as 
this bug describes, the first alert has been destroyed in the middle of its 
onload handler.  Kind of amusing.
  Maybe we shouldn't allow them to be shut down out of order. Barring that, 
luckily, a single null check in the onload handler is the only missing null check 
necessary to prevent this crash:

--- ./xpfe/appshell/src/nsWebShellWindow.cpp.1.316	Wed Oct 25 12:48:28 2000
+++ ./xpfe/appshell/src/nsWebShellWindow.cpp	Wed Oct 25 12:40:08 2000
@@ -1421,7 +1421,8 @@
 
   // fetch the chrome document URL
   nsCOMPtr<nsIContentViewer> contentViewer;
-  mDocShell->GetContentViewer(getter_AddRefs(contentViewer));
+  if (mDocShell)
+    mDocShell->GetContentViewer(getter_AddRefs(contentViewer));
   if (contentViewer) {
     nsCOMPtr<nsIDocumentViewer> docViewer = do_QueryInterface(contentViewer);
     if (docViewer) {

I'm changing the summary to reflect the part I kept here after moving the event 
part to bug 48064, and nominating it for rtm, since the patch is simple and 
harmless and prevents a crash. I forget exactly how to do this without getting my 
butt kicked, but I know adding trudelle to the cc: list may help.

Status: NEW → ASSIGNED
Keywords: rtm
Summary: NS6b3: Double-Alert Box from FORM text box 'onchange' event crashes system → crash closing double alert from text box 'onchange' event
Whiteboard: [rtm need info]

    
    

    
  
a=hyatt


    
  
Whiteboard: [rtm need info] → [rtm+] fixed on trunk

    
  
Target Milestone: --- → M19

    
    

    
  
rtm++
Whiteboard: [rtm+] fixed on trunk → [rtm++] fixed on trunk

    
    

    
  
fixed, trunk and Netscape rtm branch

Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Whiteboard: [rtm++] fixed on trunk → [rtm++]

    
    

    
  
Verified fix with 2000-11-04-09-MN6 using the above URL and attached testcase

    
    

    
  
Verifying on trunk
  Windows 2000 build 2000-11-06-09-MN6
  Windows 98 build 2000-11-06-09-MN6

There is no more crashes, but Linux RedHat6.2 still shows two alert boxes and 
the "lower" one cant be dismissed before the upper one. 
Status: RESOLVED → VERIFIED
Keywords: vtrunk

    
  
Keywords: vtrunk

          You need to log in
          before you can comment on or make changes to this bug.