Bug 99465 – testRunner.setCanOpenWindows and window.open hits an ASSERT in Mac DumpRenderTree

• Status: NEW
• Component: Tools / Tests

[Erik Arvidsson]

Created attachment 168950 [details]
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

[Alexey Proskuryakov]

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.

[Erik Arvidsson]

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

[Alexey Proskuryakov]

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.

[Erik Arvidsson]

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

[Alexey Proskuryakov]

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

[Alexey Proskuryakov]

Or perhaps you are thinking about the case of an secondary window that you don't load into, and only document.write() to?

[Erik Arvidsson]

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