Closed Bug 17835 Opened 25 years ago Closed 25 years ago

[BLOCKER][CRASHER][TESTCASE][DOGFOOD] Swapping focus,assigning value onFucus, changing window locaion crashes application.

Categories

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

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

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: desale, Assigned: joki)

References

Details

(Whiteboard: [PDT+]) 

Now this bug is little complicated to get where exact failure is.
This crash definately needs three processes to happen. First "changing focus
from one input to another input" , then second "assigning some value to second
input onFocus event" , and last is "changing window location".
If these three processes happen in order then application crashes.
[Again inputs need to be text or password.]

BUILDS:
11-02-09, 11-01-09.

STEPS TO REPRODUCE:
1] Please copy HTML code I'm providing. Save it as HTML file.
2] Open this HTML file with apprunner with above specified builds.

EXPECTED RESULTS:
First the testcase page should be loaded and then http://www.yahoo.com should be
loaded.

ACTUAL RESULTS:
Once testcase is loaded, application crashes before loading
http://www.yahoo.com. [Does not even create stack trace report window]

TESTCASE CODE START:

<HTML>
<HEAD>
<TITLE> TEST PAGE </TITLE>
</HEAD>
<BODY>
<FORM NAME="workform">
<input type=text name=testing1 size=15  >
<script LANGUAGE="JavaScript">
<!--
document.workform.testing1.focus();
//-->
</script>
<input type=password name=testing value="false"  onFocus="retresult(this);" >
<script LANGUAGE="JavaScript">
<!--
function retresult(input1){
input1.value="true";
}
document.workform.testing.focus();
location.href = "http://www.yahoo.com";
//-->
</script>
</FORM>
</BODY>
</HTML>

TESTCASE CODE END:

Vidur, you might find this little confusing, and I tried to get to exact point,
but it does not crash if I take out any of these three processes. So I guess
After assigning value to password if we try to change window location then
application crashes.

Please ask me if you need any more information on this. I tried to explain as
much as possible.
Severity: critical → blocker
Priority: P3 → P1
Summary: [CRASHER][TESTCASE] Swapping focus,assigning value onFucus, changing window locaion crashes application. → [BLOCKER][CRASHER][TESTCASE] Swapping focus,assigning value onFucus, changing window locaion crashes application.
Whiteboard: Dogfood
Tested on Windows-95, Windows-NT, Windows-98, Linux.
Assignee: vidur → joki
After considerable discussion with Joki, I'm handing it over to him. The problem
is that the JSEventListener holds a reference to the JSObject of its content
object, but the reference isn't seen by the JS garbage collector (it doesn't
create a GC root). As a result of the location.href call in the script, the
document is told to break itself down, the individual content objects drop their
GC-visible reference to their JSObject, a GC occurs and, as a result of the
document going away, a blur event fires to the INPUT element. As a result, the
JSEventListener attempts to invoke a method on an already finalized JSObject.
The stack for the crash is:

LookupProperty(JSContext * 0x018d8e50, JSObject * 0x00ebaa28, const char *
0x01c6ffb0, JSObject * * 0x0012eed4, JSProperty * * 0x0012eecc) line 1620 + 41
bytes
JS_LookupProperty(JSContext * 0x018d8e50, JSObject * 0x00ebaa28, const char *
0x01c6ffb0, long * 0x0012ef0c) line 1773 + 25 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x01c6e030) line 83 + 37 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012f1dc, nsIDOMEvent * * 0x0012f11c, unsigned int 7, nsEventStatus &
nsEventStatus_eIgnore) line 856 + 21 bytes
nsGenericElement::HandleDOMEvent(nsIPresContext & {...}, nsEvent * 0x0012f1dc,
nsIDOMEvent * * 0x0012f11c, unsigned int 1, nsEventStatus &
nsEventStatus_eIgnore) line 794
nsHTMLInputElement::HandleDOMEvent(nsHTMLInputElement * const 0x018ffecc,
nsIPresContext & {...}, nsEvent * 0x0012f1dc, nsIDOMEvent * * 0x00000000,
unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 613 + 31 bytes
nsEnderEventListener::Blur(nsIDOMEvent * 0x01c6e090) line 3207 + 68 bytes
nsEventListenerManager::HandleEvent(nsIPresContext & {...}, nsEvent *
0x0012f3d4, nsIDOMEvent * * 0x0012f390, unsigned int 7, nsEventStatus &
nsEventStatus_eIgnore) line 832 + 17 bytes
nsDocument::HandleDOMEvent(nsDocument * const 0x01c13d90, nsIPresContext &
{...}, nsEvent * 0x0012f3d4, nsIDOMEvent * * 0x0012f390, unsigned int 1,
nsEventStatus & nsEventStatus_eIgnore) line 2392
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x01c6a2c0,
nsIPresContext & {...}, nsGUIEvent * 0x0012f6d0, nsIFrame * 0x01c690a0,
nsEventStatus & nsEventStatus_eIgnore, nsIView * 0x01c67610) line 246
....


The solution we came up with is for the content to tell the event listener
manager to get rid of its JS event listeners when its gets a call to
SetScriptObject with a null parameter (i.e. when the JSObject has been
finalized). Note that if we had the JS event listener create a GC root, we would
introduce a circularity.
*** Bug 17970 has been marked as a duplicate of this bug. ***
Target Milestone: M11
Setting M11 for blockers.
Blocks: 11349
Summary: [BLOCKER][CRASHER][TESTCASE] Swapping focus,assigning value onFucus, changing window locaion crashes application. → [BLOCKER][CRASHER][TESTCASE][DOGFOOD] Swapping focus,assigning value onFucus, changing window locaion crashes application.
Whiteboard: Dogfood → [PDT+]
Setting on PDT+ radar.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
This should be fixed.
Status: RESOLVED → VERIFIED
Thanks Tom, it was really bothering our automation.
Tested with 1999-11-09-09, and its working fine. Marking verified.
You need to log in before you can comment on or make changes to this bug.