Closed
Bug 40525
Opened 25 years ago
Closed 25 years ago
Application crashes if you write on child window from parent window with document.write (nsScanner::~nsScanner)
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: desale, Assigned: harishd)
Details
(Keywords: crash)
Attachments
(2 files)
Application crashes if you write on child window from parent window with
document.write and then close child window.
If we try to close window after writing on child window from parent window with
document.write, we see application crash.
BUILDS: 2000-05-22-08.
STEPS TO REPRODUCE:
1] Load attachment I'm providing.
2] Application will automatically open one small window [Child window] onLoad.
3] Now you'll see one link "Add Text to Child Window." on parent window.
4] Click this link 5-6 times to add text on child window.
5] Now you'll see text is written on child window.
6] Now close child window. BOOOM CRASH.
EXPECTED RESULTS:
Application should not crash on closing child window.
ACTUAL RESULTS:
Application crashes.
TESTCASE START:
<HTML>
<HEAD><TITLE>Adding Text to Child Window</TITLE>
</HEAD>
<BODY>
<form name="workform">
<SCRIPT>
var w = open('about:blank', 'myWindow',
'width=600,height=400,resizable=1,scrollbars=1');
w.document.open();
</SCRIPT>
<A HREF="javascript: w.document.write('Some Text Is Written On Child
Window<br>'); void 0">
Add Text to Child Window.
</A>
</form>
</BODY>
</HTML>
TESTCASE END:
|
Reporter | |
Comment 1•25 years ago
|
||
|
||
Comment 2•25 years ago
|
||
|
|
||
Updated•25 years ago
|
Assignee: jst → rickg
Severity: normal → critical
Component: DOM Level 0 → Parser
Keywords: crash
OS: Windows 95 → All
QA Contact: desale → janc
Summary: Application crashes if you write on child window from parent window with document.write → Application crashes if you write on child window from parent window with document.write (nsScanner::~nsScanner)
|
|
||
Comment 3•25 years ago
|
||
Severity=critical, OS=All, crash kw, adding nsScanner::~nsScanner to summary.
The first 13 entries on the stack are identical to the one in bug 37178:
#0 0x40ff86f1 in nsScanner::~nsScanner ()
#1 0x40ff634d in CParserContext::~CParserContext ()
#2 0x40ff32c3 in nsParser::~nsParser ()
#3 0x40ff334d in nsParser::Release ()
#4 0x40d95349 in HTMLContentSink::~HTMLContentSink ()
#5 0x40d955f0 in HTMLContentSink::Release ()
#6 0x40fe2157 in CNavDTD::~CNavDTD ()
#7 0x40fe1dfd in CNavDTD::Release ()
#8 0x40ff6381 in CParserContext::~CParserContext ()
#9 0x40ff32c3 in nsParser::~nsParser ()
#10 0x40ff334d in nsParser::Release ()
#11 0x40d95ee4 in HTMLContentSink::DidBuildModel ()
#12 0x40fe29c9 in CNavDTD::DidBuildModel ()
#13 0x40ff426e in nsParser::DidBuildModel ()
Changing component to parser (as troy did in bug 37178),
reassigning to default owner.
Not seeing the crash. Pulled a fresh tree today (05/25/00).
Status: NEW → ASSIGNED
|
|
Reporter | |
Comment 6•25 years ago
|
||
Yeah, I'm not seeing crash with todays build either.
I can reprodice it with 05-22-08. Todays build looks ok.
Okay..marking WORKSFORME.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•