99465 2012-10-16 08:19:49 -0700 testRunner.setCanOpenWindows and window.open hits an ASSERT in Mac DumpRenderTree 2012-10-17 10:34:06 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified OS X 10.8 NEW P2 Normal --- 1 arv webkit-unassigned ap oldest_to_newest 743159 0 168950 arv 2012-10-16 08:19:49 -0700 Created attachment 168950 Layout test Open the attached file with run-webkit-test. All it does is: <script> testRunner.setCanOpenWindows(); var win = window.open(); </script> When run with Apple port of DRT I get the following stack trace: ASSERTION FAILED: gTestRunner->waitToDump() /Volumes/MacintoshHD2/src/WebKit/Tools/DumpRenderTree/mac/UIDelegate.mm(145) : -[UIDelegate webView:createWebViewWithRequest:] 1 0x10f2ca763 CallUIDelegate(WebView*, objc_selector*, objc_object*) 2 0x10f2bfdc4 WebChromeClient::createWindow(WebCore::Frame*, WebCore::FrameLoadRequest const&, WebCore::WindowFeatures const&, WebCore::NavigationAction const&) 3 0x10f668fb8 WebCore::Chrome::createWindow(WebCore::Frame*, WebCore::FrameLoadRequest const&, WebCore::WindowFeatures const&, WebCore::NavigationAction const&) const 4 0x10f920add WebCore::createWindow(WebCore::Frame*, WebCore::Frame*, WebCore::FrameLoadRequest const&, WebCore::WindowFeatures const&, bool&) 5 0x10f87baac WebCore::DOMWindow::createWindow(WTF::String const&, WTF::AtomicString const&, WebCore::WindowFeatures const&, WebCore::DOMWindow*, WebCore::Frame*, WebCore::Frame*, void (*)(WebCore::DOMWindow*, void*), void*) 6 0x10f87bfe0 WebCore::DOMWindow::open(WTF::String const&, WTF::AtomicString const&, WTF::String const&, WebCore::DOMWindow*, WebCore::DOMWindow*) 7 0x10fbcdbda WebCore::JSDOMWindow::open(JSC::ExecState*) 8 0x10fbc177f WebCore::jsDOMWindowPrototypeFunctionOpen(JSC::ExecState*) 9 0x511b92e01265 10 0x10eeab2a1 JSC::Interpreter::execute(JSC::ProgramExecutable*, JSC::ExecState*, JSC::JSObject*) 11 0x10ee03360 JSC::evaluate(JSC::ExecState*, JSC::SourceCode const&, JSC::JSValue, JSC::JSValue*) 12 0x110074081 WebCore::ScriptController::evaluateInWorld(WebCore::ScriptSourceCode const&, WebCore::DOMWrapperWorld*) 13 0x1100741f9 WebCore::ScriptController::evaluate(WebCore::ScriptSourceCode const&) 14 0x11007d0f2 WebCore::ScriptElement::executeScript(WebCore::ScriptSourceCode const&) 15 0x11007be9c WebCore::ScriptElement::prepareScript(WTF::TextPosition const&, WebCore::ScriptElement::LegacyTypeSupport) 16 0x10f9e8acb WebCore::HTMLScriptRunner::runScript(WebCore::Element*, WTF::TextPosition const&) 17 0x10f9e8930 WebCore::HTMLScriptRunner::execute(WTF::PassRefPtr<WebCore::Element>, WTF::TextPosition const&) 18 0x10f99b124 WebCore::HTMLDocumentParser::runScriptsForPausedTreeBuilder() 19 0x10f99b1a8 WebCore::HTMLDocumentParser::canTakeNextToken(WebCore::HTMLDocumentParser::SynchronousMode, WebCore::PumpSession&) 20 0x10f99aeac WebCore::HTMLDocumentParser::pumpTokenizer(WebCore::HTMLDocumentParser::SynchronousMode) 21 0x10f99b52d WebCore::HTMLDocumentParser::append(WebCore::SegmentedString const&) 22 0x10f761697 WebCore::DecodedDataDocumentParser::flush(WebCore::DocumentWriter*) 23 0x10f79e0ae WebCore::DocumentWriter::end() 24 0x10f791a53 WebCore::DocumentLoader::finishedLoading() 25 0x10fe554c0 WebCore::MainResourceLoader::didFinishLoading(double) 26 0x7fff932a0f58 __65-[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:]_block_invoke_0 27 0x7fff932a0e9c -[NSURLConnectionInternal _withConnectionAndDelegate:onlyActive:] 28 0x7fff932a0d98 -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] 29 0x7fff96308f01 ___delegate_didFinishLoading_block_invoke_0 30 0x7fff962fb3ca ___withDelegateAsync_block_invoke_0 31 0x7fff9638b56a __block_global_1 743586 1 ap 2012-10-16 14:48:04 -0700 This seems to be intentional - tests that use window.open() should also use waitUntilDone, because you have to wait for load. We have a number of tests that use testRunner.setCanOpenWindows and pass. 744228 2 arv 2012-10-17 07:23:35 -0700 (In reply to comment #1) > This seems to be intentional - tests that use window.open() should also use waitUntilDone, because you have to wait for load. That is not true. window.open is synchronous and forcing tests to be async is bad. 744292 3 ap 2012-10-17 09:06:09 -0700 What exactly did you find untrue? You just seem to disagree. Saying that window.open() is synchronous is not meaningful - every function call is. But actually loading anything into the opened window is not. We have a lot of tests where waitUntilDone was appropriate, so if you have one more test that doesn't need that, please post an explanation why you cannot follow the common model. 744297 4 arv 2012-10-17 09:13:53 -0700 (In reply to comment #3) > What exactly did you find untrue? You just seem to disagree. The following works and the web depend on it. var win = window.open(); win.document.body.whatever The DOM in the newly opened window is available synchronously. 744358 5 ap 2012-10-17 10:17:21 -0700 I just tested to confirm that win.document.body.innerHTML is empty in this scenario. Are you by any chance thinking about some special case, like a data or a javascript URL? main.html: ---------- <script> try { var w = window.open("w.html"); alert(w.document.body.innerHTML); setTimeout("alert(w.document.body.innerHTML)", 100); } catch (ex) { alert("Please disable your popup blocker, and/or local file security"); } </script> ---------- w.html: ---------- <body>Huh?</body> ---------- 744364 6 ap 2012-10-17 10:22:11 -0700 Or perhaps you are thinking about the case of an secondary window that you don't load into, and only document.write() to? 744379 7 arv 2012-10-17 10:34:06 -0700 (In reply to comment #6) > Or perhaps you are thinking about the case of an secondary window that you don't load into, and only document.write() to? Yup. When you do window.open you synchronously get about:blank which has a body element (you didn't get an exception in your test). You can manipulate this using DOM and/or document.write to it. 168950 2012-10-16 08:19:49 -0700 2012-10-16 08:19:49 -0700 Layout test test-runner-set-can-open-windows.html text/html 66 arv PHNjcmlwdD4KdGVzdFJ1bm5lci5zZXRDYW5PcGVuV2luZG93cygpOwp3aW5kb3cub3BlbigpOwo8 L3NjcmlwdD4K