crash closing double alert from text box 'onchange' event

VERIFIED FIXED

Status

()

Core
DOM: Core & HTML
P1
critical
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: William C. Dickinson, Assigned: Dan M)

Tracking

({crash})

Trunk
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rtm++], URL)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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>
(Reporter)

Comment 1

18 years ago
Associated bug reported under #57515

Comment 2

18 years ago
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

Comment 3

18 years ago
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

Comment 4

18 years ago
Created attachment 17920 [details]
above testcase

Comment 5

18 years ago
See bug 48064 - this bug may be related / a duplicate
(Reporter)

Comment 6

18 years ago
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
(Assignee)

Comment 8

18 years ago
  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]

Comment 9

18 years ago
a=hyatt
(Assignee)

Updated

18 years ago
Whiteboard: [rtm need info] → [rtm+] fixed on trunk
(Assignee)

Updated

18 years ago
Target Milestone: --- → M19

Comment 11

18 years ago
rtm++
Whiteboard: [rtm+] fixed on trunk → [rtm++] fixed on trunk
(Assignee)

Comment 12

18 years ago
fixed, trunk and Netscape rtm branch
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [rtm++] fixed on trunk → [rtm++]

Comment 13

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

Comment 14

18 years ago
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

Updated

18 years ago
Keywords: vtrunk
You need to log in before you can comment on or make changes to this bug.