With a build from 3/26, win32, I see tons of assertions in nsFrame.cpp, not a container, at: nsDebug::Assertion(const char * 0x02530530, const char * 0x02530524, const char * 0x025304e4, int 350) line 286 + 13 bytes nsDebug::PreCondition(const char * 0x02530530, const char * 0x02530524, const char * 0x025304e4, int 350) line 430 + 21 bytes nsFrame::AppendFrames(nsFrame * const 0x0283e35c, nsIPresContext * 0x036ffee0, nsIPresShell & {...}, nsIAtom * 0x00000000, nsIFrame * 0x0283e398) line 350 + 35 bytes FrameManager::AppendFrames(FrameManager * const 0x036a2ac0, nsIPresContext * 0x036ffee0, nsIPresShell & {...}, nsIFrame * 0x0283e35c, nsIAtom * 0x00000000, nsIFrame * 0x0283e398) line 779 nsCSSFrameConstructor::AppendFrames(nsIPresContext * 0x036ffee0, nsIPresShell * 0x036a0d50, nsIFrameManager * 0x036a2ac0, nsIContent * 0x03731f70, nsIFrame * 0x0283e35c, nsIFrame * 0x0283e398) line 7582 + 30 bytes nsCSSFrameConstructor::ContentAppended(nsCSSFrameConstructor * const 0x036a7b50, nsIPresContext * 0x036ffee0, nsIContent * 0x03731f70, int 0) line 8133 StyleSetImpl::ContentAppended(StyleSetImpl * const 0x036a7c80, nsIPresContext * 0x036ffee0, nsIContent * 0x03731f70, int 0) line 1215 PresShell::ContentAppended(PresShell * const 0x036a0d58, nsIDocument * 0x036e9a80, nsIContent * 0x03731f70, int 0) line 4406 + 46 bytes nsDocument::ContentAppended(nsDocument * const 0x036e9a80, nsIContent * 0x03731f70, int 0) line 1596 nsHTMLDocument::ContentAppended(nsHTMLDocument * const 0x036e9a80, nsIContent * 0x03731f70, int 0) line 1256 HTMLContentSink::NotifyAppend(nsIContent * 0x03731f70, int 0) line 4544 SinkContext::FlushTags(int 1) line 2047 .......

makes using debug builds beyond painful.

I'm not seeing this on my home machine which was built yesterday and has all of the changes I made after that. I guess it must have happened after yesterday by someone else. I'll try to find out what caused it on a fresh tree.

Adding www.washingtonpost to url. The problem is with the IFRAME. nsCSSFrameConstructor::ContentAppended() line 8125 has a aContainer set to an nsHTMLIFrameElement but aParentFrame is set to an nsHTMLFrameOuterFrame. This is not right and since nsHTMLFrameOuterFrame does not override AppendFrames or derive from something that does we get the assertion. Reassigning to pollmann and changing the component to HTMLFrames.

nominating for mozilla0.9. This bug is confusing a lot of other bugs and needs to be fixed.

*** Bug 75258 has been marked as a duplicate of this bug. ***

Sounds like "developer dogfood" to me. :) I'm not sure what the fix should be, but I'll take a look.

This stops us from creating child frames for <iframe> and <frame> frames. By heading off the append here, we save work, and prevent the frames from leaking like they would if we just over-rode AppendFrames and did nothing with them.

r=pavlov this patch fixes bug 74113 as well.

Fix checked in. To verify, view the first attachment "reduced test case" in a debug build. You should see the page load (mozilla.org inside of an iframe) with no assertions. Alternatively, view the testcase on 74113, and reload - you should not see a crash. (This second test does not require a debug build)

*** Bug 73407 has been marked as a duplicate of this bug. ***

Marking verified in the May 21 build.