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/ | ||
Alexey Proskuryakov
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()
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Alexey Proskuryakov
Could be duplicate of bug 50312.
Eric Seidel (no email)
I'm amazed it took this long to find a regression from that (scary) change. I can look into this tomorrow or monday.
Eric Seidel (no email)
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.
Eric Seidel (no email)
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 ***