35726 - assertion in HTMLContentSink::EvaluateScript

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[Warren Harris]

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 
307
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()
01009a40()

Comment 1

[Warren Harris]

Ok, you'll hit the assertion if you go to the url specified above.

Comment 2

[Warren Harris]

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.

Comment 3

[troy]

Reassigning to jst

Comment 4

[Richard Zach]

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.

Comment 5

[Johnny Stenback (:jst)]

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 ***

Comment 6

[Richard Zach]

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.

Comment 7

[Warren Harris]

Reopening for recursive load problem. Reassigning to danm.

Comment 8

[Warren Harris]

=> danm

Comment 9

[Peter Trudelle]

crashes today's build on Win98, still gets into an endless loop on Linux. 
Nominating for nsbeta2, bumping severity to critical, adding crash keyword

Comment 10

[Peter Trudelle]

[nsbeta2+]

Comment 11

[Dan M]

  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.

Comment 12

[Michael La Guardia]

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.

Comment 13

[Dan M]

  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 
beta2+.

Comment 14

[Jay Patel [:jay]]

Putting on [nsbeta2-] radar. Not critical to beta2. PSM is always installed in 
the commercial builds, so this should not be a problem.

Comment 15

[Peter Trudelle]

Not a problem in current opt verification builds. ->future

Comment 16

[Boris Zbarsky [:bzbarsky]]

I no longer see this assertion on that page...