Bug 65946 – load event for topmost frame dispatched within the context of appendChild(iframe)

• Component: Page Loading
• Status: NEW

[Darin Fisher (:fishd, Google)]

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.

[Darin Fisher (:fishd, Google)]

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

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.

ah nice, that's a test case we've been looking for in https://bugs.webkit.org/show_bug.cgi?id=82931

[Ojan Vafai]

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