Bug 54711

Summary:	Assertion failure in HTMLFrameElementBase::insertedIntoDocument() when opening comcast.net main page
Product:	WebKit	Reporter:	Alexey Proskuryakov <ap>
Component:	Layout and Rendering	Assignee:	Nobody <webkit-unassigned>
Status:	RESOLVED DUPLICATE
Severity:	Normal	CC:	aestes, dglazkov, eric, rniwa, simon.fraser
Priority:	P2	Keywords:	NeedsReduction
Version:	528+ (Nightly build)
Hardware:	Mac
OS:	OS X 10.6
URL:	http://www.comcast.net/

Description Alexey Proskuryakov 2011-02-17 20:46:15 PST

Looks like one needs to be logged in. Then, opening http://www.comcast.net/ usually crashes with an assertion.

The assertion is fairly new, it has been added in <http://trac.webkit.org/changeset/67182>.

ASSERTION FAILED: !renderer()
/Users/ap/Safari/OpenSource/Source/WebCore/html/HTMLFrameElementBase.cpp(188) : virtual void WebCore::HTMLFrameElementBase::insertedIntoDocument()
 -> WebCore::HTMLFrameElementBase::insertedIntoDocument()
 -> WebCore::HTMLIFrameElement::insertedIntoDocument()
 -> WebCore::ContainerNode::insertedIntoDocument()
 -> WebCore::Element::insertedIntoDocument()
 -> WebCore::ContainerNode::insertedIntoDocument()
 -> WebCore::Element::insertedIntoDocument()
 -> WebCore::ContainerNode::insertedIntoDocument()
 -> WebCore::Element::insertedIntoDocument()
 -> WebCore::ContainerNode::insertedIntoDocument()
 -> WebCore::Element::insertedIntoDocument()
 -> WebCore::ContainerNode::insertedIntoDocument()
 -> WebCore::Element::insertedIntoDocument()
 -> WebCore::ContainerNode::insertedIntoDocument()
 -> WebCore::Element::insertedIntoDocument()
 -> WebCore::notifyChildInserted(WebCore::Node*)
 -> WebCore::ContainerNode::replaceChild(WTF::PassRefPtr<WebCore::Node>, WebCore::Node*, int&, bool)
 -> WebCore::Node::replaceChild(WTF::PassRefPtr<WebCore::Node>, WebCore::Node*, int&, bool)
 -> WebCore::JSNode::replaceChild(JSC::ExecState*)
 -> WebCore::jsNodePrototypeFunctionReplaceChild(JSC::ExecState*)
 -> 0x2ca8bcc001b8
 -> JSC::JITCode::execute(JSC::RegisterFile*, JSC::ExecState*, JSC::JSGlobalData*)
 -> JSC::Interpreter::executeCall(JSC::ExecState*, JSC::JSObject*, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)
 -> JSC::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)
 -> WebCore::JSMainThreadExecState::call(JSC::ExecState*, JSC::JSValue, JSC::CallType, JSC::CallData const&, JSC::JSValue, JSC::ArgList const&)
 -> WebCore::JSEventListener::handleEvent(WebCore::ScriptExecutionContext*, WebCore::Event*)
 -> WebCore::EventTarget::fireEventListeners(WebCore::Event*, WebCore::EventTargetData*, WTF::Vector<WebCore::RegisteredEventListener, 1ul>&)
 -> WebCore::EventTarget::fireEventListeners(WebCore::Event*)
 -> WebCore::Node::handleLocalEvents(WebCore::Event*)
 -> WebCore::Node::dispatchGenericEvent(WTF::PassRefPtr<WebCore::Event>)
 -> WebCore::Node::dispatchEvent(WTF::PassRefPtr<WebCore::Event>)
 -> WebCore::Document::finishedParsing()

Comment 1 Alexey Proskuryakov 2011-02-17 20:46:55 PST

Could be duplicate of bug 50312.

Comment 2 Eric Seidel (no email) 2011-02-17 23:38:49 PST

I'm amazed it took this long to find a regression from that (scary) change.  I can look into this tomorrow or monday.

Comment 3 Eric Seidel (no email) 2011-02-17 23:40:17 PST

I feel like someone else was recently playing in this area... I wonder if this is a regression from a more recent build.  Would be nice to get a reduction and do a bisect-builds.

Comment 4 Eric Seidel (no email) 2012-01-03 13:41:16 PST

www.comcast.net loads http://xfinity.comcast.net/ for me, but doesn't crash in a Debug build on my machine.  I'm sure this is a dupe of bug 50312, but we really need a reduction/consistent repro.

*** This bug has been marked as a duplicate of bug 50312 ***