Closed
Bug 6580
Opened 26 years ago
Closed 25 years ago
Using content's parent pointer after doc destruction crashes
Categories
(Core :: Layout, defect, P3)
Tracking
()
VERIFIED
FIXED
M12
People
(Reporter: morse, Assigned: joki)
References
()
Details
(Whiteboard: stack trace in file)
Display content shown below but with the commented lines uncommented. You
should see a link that say "click me" and a text (not a link) that says
"thanks". Click on the the "click me" link. It crashes and you get stack trace
as shown below the content.
OK, as I work-around replace the comments and use the original content as shown.
Now you don't crash when you click on the "click me" link. But what is supposed
to happen next is that the original "click me" link becomes the text "thanks"
and a new "click me" link should appear where the old text "thanks" was.
Instead you get one big link that says "click me thanks". That's bad of course
but worse is if you press on the "click me" side of it you get the crash.
Interestingly if you press on the "thanks" side of it you don't crash and the
display changes to the original display as it should. By using this trick
and always pressing on the right side of the composite link, everything appears
to work for a while. But after repeated pressing of the link many many times,
it eventually too gives the crash.
Note: this script was attempted as a work-around for the bug 1646 that was
blocking wallet. It would have been an acceptable work-around if it worked. So
wallet is blocked until at least one of these two bugs is fixed.
<HTML>
<HEAD>
<TITLE>Signons</TITLE>
<SCRIPT>
index_frame = 0;
function loadSignons(){
top.frames[index_frame].document.open();
top.frames[index_frame].document.write(
"<BODY>" +
"<TABLE>" +
"<TR>" +
// "<TD>" +
"Thanks....." +
// "</TD>" +
// "<TD>" +
"<A ONCLICK=top.loadRejects(); HREF= >" +
".....Click me" +
"</A>" +
// "</TD>" +
"</TR>" +
"</TABLE>" +
"</BODY>"
);
top.frames[index_frame].document.close();
}
function loadRejects(){
top.frames[index_frame].document.open();
top.frames[index_frame].document.write(
"<BODY>" +
"<TABLE>" +
"<TR>" +
// "<TD>" +
"<A ONCLICK=top.loadSignons(); HREF= >" +
"Click me....." +
"</A>" +
// "</TD>" +
// "<TD>" +
".....Thanks" +
// "</TD>" +
"</TR>" +
"</TABLE>" +
"</BODY>"
);
top.frames[index_frame].document.close();
}
</SCRIPT>
</HEAD>
<FRAMESET ROWS = 25,25 onLoad=loadSignons()>
<FRAME SRC=about:blank>
<FRAME SRC=about:blank>
</FRAMESET>
<NOFRAMES>
<BODY> <P> </BODY>
</NOFRAMES>
</HTML>
nsGenericElement::GetParent(nsIContent * & 0x0277c2ec) line 708 + 24 bytes
nsHTMLAnchorElement::GetParent(const nsHTMLAnchorElement * const 0x0277c2ec,
nsIContent * & 0x0277c2ec) line 101 + 18 bytes
nsCSSFrameConstructor::RecreateFramesForContent(nsIPresContext * 0x01334b30,
nsIContent * 0x0277c2ec) line 5448 + 16 bytes
nsCSSFrameConstructor::ContentStatesChanged(nsCSSFrameConstructor * const
0x01338820, nsIPresContext * 0x01334b30, nsIContent * 0x00000000, nsIContent *
0x0277c2ec) line 4678 + 16 bytes
StyleSetImpl::ContentStatesChanged(StyleSetImpl * const 0x01338790,
nsIPresContext * 0x01334b30, nsIContent * 0x0275b65c, nsIContent * 0x0277c2ec)
line 854
PresShell::ContentStatesChanged(PresShell * const 0x013388b8, nsIDocument *
0x01333610, nsIContent * 0x0275b65c, nsIContent * 0x0277c2ec) line 1616 + 46
bytes
nsDocument::ContentStatesChanged(nsDocument * const 0x01333610, nsIContent *
0x0275b65c, nsIContent * 0x0277c2ec) line 1475
nsEventStateManager::SetContentState(nsEventStateManager * const 0x02740790,
nsIContent * 0x0275b65c, int 4) line 971
nsEventStateManager::GenerateMouseEnterExit(nsIPresContext & {...}, nsGUIEvent *
0x0012fcb0) line 370
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x02740790,
nsIPresContext & {...}, nsGUIEvent * 0x0012fcb0, nsIFrame * 0x0275c3d0,
nsEventStatus & nsEventStatus_eIgnore) line 109
PresShell::HandleEvent(PresShell * const 0x013388b4, nsIView * 0x026f3be0,
nsGUIEvent * 0x0012fcb0, nsEventStatus & nsEventStatus_eIgnore) line 1993 + 39
bytes
nsView::HandleEvent(nsView * const 0x026f3be0, nsGUIEvent * 0x0012fcb0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore) line 831
nsView::HandleEvent(nsView * const 0x026f3230, nsGUIEvent * 0x0012fcb0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore) line 818
nsView::HandleEvent(nsView * const 0x026f3160, nsGUIEvent * 0x0012fcb0, unsigned
int 8, nsEventStatus & nsEventStatus_eIgnore) line 818
nsView::HandleEvent(nsView * const 0x01338500, nsGUIEvent * 0x0012fcb0, unsigned
int 28, nsEventStatus & nsEventStatus_eIgnore) line 818
nsViewManager::DispatchEvent(nsViewManager * const 0x01338ec0, nsGUIEvent *
0x0012fcb0, nsEventStatus & nsEventStatus_eIgnore) line 1726
HandleEvent(nsGUIEvent * 0x0012fcb0) line 67
nsWindow::DispatchEvent(nsWindow * const 0x026f3304, nsGUIEvent * 0x0012fcb0,
nsEventStatus & nsEventStatus_eIgnore) line 410 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fcb0) line 431
nsWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line 2878 +
15 bytes
ChildWindow::DispatchMouseEvent(unsigned int 300, nsPoint * 0x00000000) line
3027
nsWindow::ProcessMessage(unsigned int 512, unsigned int 0, long 1048734, long *
0x0012fe48) line 2229 + 24 bytes
nsWindow::WindowProc(void * 0x0c610580, unsigned int 512, unsigned int 0, long
1048734) line 474 + 27 bytes
USER32! 77e71250()
|
||
Updated•26 years ago
|
Whiteboard: stack trace in file
|
||
Updated•26 years ago
|
Status: NEW → ASSIGNED
|
|
||
Updated•26 years ago
|
|
|
||
Comment 1•26 years ago
|
||
To eliminate html frame/sets from the equation, I rewrote this example:
http://blueviper/frames/crash6580.html
<HTML>
<HEAD>
<SCRIPT>
var content = "<BODY><A ONCLICK=load() HREF=>Click me</A></BODY>"
function load(){
document.open()
document.write(content)
document.close()
}
</SCRIPT>
</HEAD>
<BODY ONLOAD=load()></BODY>
</HTML>
This will crash with an identical stack trace. However, this crash is related
to when the mouse pointer leaves the anchor in relation to when the document is
destroyed and rewritten. To reproduce the crash you must:
1) Go to the above URL.
2) Click on the link.
3) Immediately move the mouse pointer off of the link, but keep it inside the
document window.
4) Wait for the page to be destroyed, then rewritten.
5) Watch in exasperation as viewer crashes.
If you leave the document window in step 3, the crash will not occur until the
mouse re-enters the document window.
If your computer is too fast to move the pointer before the document is redrawn
(I certainly don't have that problem on my P166), set a breakpoint in
CNavDTD::SetContentState. After you click on the link, this breakpoint will be
hit. Move your mouse pointer off of the link, then continue execution (pres F5
to keep the mouse inside the document window).
I set a few breakpoints, and found that the mouse pointer must be moved before
the new document is written (before CNavDTD::BuildModel is called), or no crash
will occur. In Steve's example, a new link is written into a different
location, so the mouse pointer doesn't have to be moved to see the crash.
Interestingly, I also noticed that on clicking the link, the document that is
being document.written is actually parsed twice. (SetContentState is called,
BuildModel is called with "<BODY><A...", BuildModel is called with "</HTML>",
and then the cycle is repeated) This shouldn't be happening as far as I can
tell...
Since this entire bug revolves around code I know very little about (events,
parsing, and javascript), it would be my pleasure to give it to somebody who
fully understands the issues - any takers?
|
|
||
Comment 2•26 years ago
|
||
Opps, I wrote:
...set a breakpoint in CNavDTD::SetContentState...
When I meant to write:
...set a breakpoint in nsEventStateManager::SetContentState...
:)
|
Assignee | |
Updated•26 years ago
|
Assignee: pollmann → joki
Status: ASSIGNED → NEW
Summary: [BLOCKING WALLET] Rewriting frames causes crash → Using content's parent pointer after doc destruction crashes
Target Milestone: M12
|
|
Assignee | |
Comment 3•26 years ago
|
||
Okay, I've checked it a fix for this. We now check to see if content has been
removed from the document before we try to set its content state. However, this
bug is indicative of a larger problem in that when a single piece of content is
held onto after document destruction, not all of it external refs are still
valid. In this case, the parent pointer is invalid. Still need to fix that.
Removng blocker status and pushing to later milestone.
|
|
Assignee | |
Updated•25 years ago
|
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
|
|
Assignee | |
Comment 4•25 years ago
|
||
So the additional bug with bad parent pointers I mentioned was fixed by
waterson@netscape.com a little while back. So this should be completely fixed
now.
|
||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
|
|
||
Comment 5•25 years ago
|
||
With the Dec 01 build (1999120108), this problem has been fixed.
You need to log in
before you can comment on or make changes to this bug.
Description
•