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()

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

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

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.

=> danm

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

[nsbeta2+]

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.

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

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

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

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