NEW 65946
load event for topmost frame dispatched within the context of appendChild(iframe) 
https://bugs.webkit.org/show_bug.cgi?id=65946
Summary load event for topmost frame dispatched within the context of appendChild(ifr...
Darin Fisher (:fishd, Google)
Reported 2011-08-09 15:02:35 PDT
Created attachment 103404 [details] testcase load event for topmost frame dispatched within the context of appendChild(iframe) In my testcase, I create an iframe from inline script. I attach an onload handler to the iframe. From the onload event handler, I insert another iframe. During insertion of the second iframe, the load event for the topmost frame fires. Call stack: webkit.dll!WebCore::Document::dispatchWindowLoadEvent() Line 3422 C++ webkit.dll!WebCore::Document::implicitClose() Line 2134 C++ webkit.dll!WebCore::FrameLoader::checkCallImplicitClose() Line 795 C++ webkit.dll!WebCore::FrameLoader::checkCompleted() Line 744 C++ webkit.dll!WebCore::FrameLoader::completed() Line 1082 C++ webkit.dll!WebCore::FrameLoader::checkCompleted() Line 747 C++ webkit.dll!WebCore::Document::explicitClose() Line 2091 C++ webkit.dll!WebCore::Document::cancelParsing() Line 1990 C++ webkit.dll!WebCore::FrameLoader::init() Line 239 C++ webkit.dll!WebCore::Frame::init() Line 287 C++ > webkit.dll!WebKit::WebFrameImpl::createChildFrame(const WebCore::FrameLoadRequest & request={...}, WebCore::HTMLFrameOwnerElement * ownerElement=0x0b2c19c8) Line 1908 C++ webkit.dll!WebKit::FrameLoaderClientImpl::createFrame(const WebCore::KURL & url={...}, const WTF::String & name={...}, WebCore::HTMLFrameOwnerElement * ownerElement=0x0b2c19c8, const WTF::String & referrer={...}, bool allowsScrolling=true, int marginWidth=-1, int marginHeight=-1) Line 1438 + 0x1a bytes C++ webkit.dll!WebCore::SubframeLoader::loadSubframe(WebCore::HTMLFrameOwnerElement * ownerElement=0x0b2c19c8, const WebCore::KURL & url={...}, const WTF::String & name={...}, const WTF::String & referrer={...}) Line 265 + 0x85 bytes C++ webkit.dll!WebCore::SubframeLoader::loadOrRedirectSubframe(WebCore::HTMLFrameOwnerElement * ownerElement=0x0b2c19c8, const WebCore::KURL & url={...}, const WTF::AtomicString & frameName={...}, bool lockHistory=true, bool lockBackForwardList=true) Line 240 + 0x43 bytes C++ webkit.dll!WebCore::SubframeLoader::requestFrame(WebCore::HTMLFrameOwnerElement * ownerElement=0x0b2c19c8, const WTF::String & urlString={...}, const WTF::AtomicString & frameName={...}, bool lockHistory=true, bool lockBackForwardList=true) Line 83 + 0x21 bytes C++ webkit.dll!WebCore::HTMLFrameElementBase::openURL(bool lockHistory=true, bool lockBackForwardList=true) Line 103 C++ webkit.dll!WebCore::HTMLFrameElementBase::setNameAndOpenURL() Line 154 C++ webkit.dll!WebCore::HTMLFrameElementBase::insertedIntoDocument() Line 188 C++ webkit.dll!WebCore::HTMLIFrameElement::insertedIntoDocument() Line 151 C++ webkit.dll!WebCore::notifyChildInserted(WebCore::Node * child=0x0b2c19c8) Line 1084 + 0x1d bytes C++ webkit.dll!WebCore::ContainerNode::appendChild(WTF::PassRefPtr<WebCore::Node> newChild={...}, int & ec=0, bool shouldLazyAttach=true) Line 650 + 0x9 bytes C++ It looks like this is related to the fact that the iframe is inserted with an empty URL before we tell it to navigate. Upon insertion, when the URL is empty, we perform 'load' processing, which triggers the topmost frame to think that everything is complete.
Attachments
testcase (925 bytes, text/html)
2011-08-09 15:02 PDT, Darin Fisher (:fishd, Google) 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Darin Fisher (:fishd, Google)
Comment 1 2011-08-09 15:04:16 PDT
I confirmed that both IE9 and FF5 do not exhibit this bazaar behavior. In both of those browsers, the load event for the topmost frame is deferred until the two child frames have finished loading. The behavior of IE9 and FF5 seems correct to me.
Darin Fisher (:fishd, Google)
Comment 2 2011-08-09 15:20:30 PDT
This old change also seems symptomatic of the same problem: http://trac.webkit.org/changeset/35088 There Brady was trying to workaround the problem that the parent's load event could fire during Frame::init(). On the Chrome side, we saw similar issues here: https://bugs.webkit.org/show_bug.cgi?id=18135 (Though that bug was closed without a fix, we apparently ended up with a fix that resembles Brady's patch.) It seems like we should not be dispatching the load event for the parent frame when inserting a child iframe.
jochen
Comment 3 2012-05-09 13:34:13 PDT
ah nice, that's a test case we've been looking for in https://bugs.webkit.org/show_bug.cgi?id=82931
Ojan Vafai
Comment 4 2013-02-19 12:11:43 PST
(In reply to comment #3) > ah nice, that's a test case we've been looking for in https://bugs.webkit.org/show_bug.cgi?id=82931 Yes! It would be great if our fix for this was to just fix bug 82931.
Note You need to log in before you can comment on or make changes to this bug.