Closed Bug 35726 Opened 25 years ago Closed 22 years ago

assertion in HTMLContentSink::EvaluateScript


(Core :: Layout, defect, P3)

Windows NT





(Reporter: warrensomebody, Assigned: danm.moz)




(Whiteboard: [nsbeta2-])

I hit this assertion all the time. Please fix/remove. It seems harmless when you 
proceed from it. Unfortunately, I don't remember what I clicked on this time to 
hit it.

NTDLL! 77f7629c()
nsDebug::Assertion(const char * 0x01d73670, const char * 0x01d73660, const char 
* 0x01d73614, int 0x000010cc) line 191 + 13 bytes
nsDebug::WarnIfFalse(const char * 0x01d73670, const char * 0x01d73660, const 
char * 0x01d73614, int 0x000010cc) line 249 + 21 bytes
HTMLContentSink::EvaluateScript(nsString & {"var oAtomPopUp;

function popWin(url) {
	if ((oAtomPopUp)&& (!oAtomPopUp.closed)) { oAtomPopUp.location=url; }
	else {
		"}, nsIURI * 0x0723d890, int 0x00000001, const char * 
0x0032b468) line 4300 + 38 bytes
HTMLContentSink::OnStreamComplete(HTMLContentSink * const 0x071b9484, 
nsIStreamLoader * 0x0723d920, nsISupports * 0x00000000, unsigned int 0x00000000, 
unsigned int 0x00000118, const char * 0x06f509a0) line 4395 + 42 bytes
nsStreamLoader::OnStopRequest(nsStreamLoader * const 0x0723d924, nsIChannel * 
0x0723e8d0, nsISupports * 0x00000000, unsigned int 0x00000000, const unsigned 
short * 0x00000000) line 120 + 78 bytes
InterceptStreamListener::OnStopRequest(InterceptStreamListener * const 
0x06f50cc0, nsIChannel * 0x0723e8d0, nsISupports * 0x00000000, unsigned int 
0x00000000, const unsigned short * 0x00000000) line 1120
nsHTTPChannel::ResponseCompleted(nsIStreamListener * 0x06f50cc0, unsigned int 
0x00000000, const unsigned short * 0x00000000) line 1486 + 36 bytes
nsHTTPServerListener::OnStopRequest(nsHTTPServerListener * const 0x0700cf40, 
nsIChannel * 0x071e10b4, nsISupports * 0x0723e8d0, unsigned int 0x00000000, 
const unsigned short * 0x00000000) line 598
nsOnStopRequestEvent::HandleEvent(nsOnStopRequestEvent * const 0x06f51900) line 
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x06f518b0) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x06f518b0) line 563 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01009a40) line 508 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x02f1078e, unsigned int 0x0000c0a2, unsigned int 
0x00000000, long 0x01009a40) line 1018 + 9 bytes
USER32! 77e71820()
Ok, you'll hit the assertion if you go to the url specified above.
I see that that page seems to be repeatedly loading too (at least in my build). 
It asserts, then if you continue, it starts to lay out, and then repeats. 
Perhaps Ruslan should look at this first.
Reassigning to jst
Assignee: troy → jst
This is the problem with the new navigator.content property conflicting with
windows/frames named "content".  See bug 31378 (assigned to danm).  Same URL
reported problems for same reason in bug 35692.
zach, I assume you're right, marking as dup, it that's not the case then someone
please reopend this. Thanks for looking into this zach!

*** This bug has been marked as a duplicate of 31378 ***
Closed: 25 years ago
Resolution: --- → DUPLICATE
Well, the repeated loading is due to the fact that one of the frames tries to
load something in the "content" frame, and because of bug 31378 it ends up in
the top frame.  I don't know if the assert is related to this.  Maybe danm
should have a look.
Reopening for recursive load problem. Reassigning to danm.
Resolution: DUPLICATE → ---
=> danm
Assignee: jst → danm
Depends on: 33650
Target Milestone: --- → M17
crashes today's build on Win98, still gets into an endless loop on Linux. 
Nominating for nsbeta2, bumping severity to critical, adding crash keyword
Severity: normal → critical
Keywords: crash, nsbeta2
Whiteboard: [nsbeta2+]
Blocks: 40158
  Bug 33650 has been fixed, or at least made better enough. This page seems 
better behaved; at least, no endless loops or crashes. But it still doesn't quite 
load correctly. And Warren's Assertion still happens.
  Richard, can you tell me why you pegged these problems on the "content" frame 
bug? The assertion happens because an attempt is made to use as a context for 
executing a script, an nsDocument that's had its script context cleared out. 
Sound familiar to anyone? Not me.
According to danm's 6/22 comments, the crash in this bug has been fixed.  Does
this still block us from shipping beta2?  Removing the nsbeta2+ for reconsideration.
Whiteboard: [nsbeta2+]
  True, this doesn't crash or hang (any longer?). But this webpage is still 
pretty misbehaved. And the assertion still happens. So the original complaint 
still stands. But I suppose it's reasonable to re-think whether it should be 
Putting on [nsbeta2-] radar. Not critical to beta2. PSM is always installed in 
the commercial builds, so this should not be a problem.
Whiteboard: [nsbeta2-]
Not a problem in current opt verification builds. ->future
Target Milestone: M17 → Future
No longer blocks: 40158
Keywords: crash
I no longer see this assertion on that page...
Closed: 25 years ago22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.