fast/loader/create-frame-in-DOMContentLoaded.html has been asserting in FrameLoader::loadWithDocumentLoader on Windows since it was added in r90038 <http://trac.webkit.org/changeset/90038>: http://build.webkit.org/results/Windows%20XP%20Debug%20(Tests)/r90031%20(30136)/results.html passed http://build.webkit.org/results/Windows%20XP%20Debug%20(Tests)/r90039%20(30140)/results.html failed
Added to the Windows Skipped file in r90236 http://trac.webkit.org/changeset/90236
<rdar://problem/9711373>
Thanks for adding to the skipped file. I am surprised this failed on Windows.
Created attachment 131585 [details] Patch v1
Comment on attachment 131585 [details] Patch v1 Will upload another patch with the test case being removed from Skipped list for Windows
Created attachment 131588 [details] Patch v2
Comment on attachment 131588 [details] Patch v2 Attachment 131588 [details] did not pass chromium-ews (chromium-xvfb): Output: http://queues.webkit.org/results/11943480 New failing tests: fast/events/form-iframe-target-before-load-crash2.html fast/dom/Document/readystate.html fast/loader/onload-policy-ignore-for-frame.html fast/events/form-iframe-target-before-load-crash.html
Comment on attachment 131588 [details] Patch v2 View in context: https://bugs.webkit.org/attachment.cgi?id=131588&action=review > Source/WebCore/ChangeLog:13 > + After creation of an initial document in Frame::init(),"load" event is triggered which is causing > + the problem. In accordance with the fix being made in https://bugs.webkit.org/show_bug.cgi?id=63483 > + preventing "load" event being fired for initial document. Do we know why this only affects Windows?
Comment on attachment 131588 [details] Patch v2 View in context: https://bugs.webkit.org/attachment.cgi?id=131588&action=review This change seems strange to me, but the link to the build output is dead, so I'm short on context. Regardless, I'm pretty sure that this isn't the right place to exit for this particular case. > Source/WebCore/loader/FrameLoader.cpp:715 > + if (m_stateMachine.creatingInitialEmptyDocument()) > + return; It looks like this patch is causeing test failures (based on the cr-linux bot output). This seems like an overly broad place to do this check anyway. I would suggest trying it in Document::implicitClose().
We no longer hit this problem with current WebKit.