[Win][DumpRenderTree] Some js tests are randomly timing out AppleWin EWS layout tests are observing random timeout for some js tests. For exameple, attachment 417783 [details] https://ews-build.s3-us-west-2.amazonaws.com/Windows-EWS/r417783-72338/results.html js/dfg-float64array.html attachment 417792 [details] https://ews-build.s3-us-west-2.amazonaws.com/Windows-EWS/r417792-72345/results.html js/dfg-inline-arguments-out-of-bounds.html These js tests generates very long page. It takes long time to resetWebViewToConsistentStateBeforeTesting after testing. See also Bug 220145.
It's easy to reproduce this issue by invoking DumpRenderTree.exe directly. .\WebKitBuild\Debug\bin64\DumpRenderTree.exe file:///C:/webkit/LayoutTests/js/dfg-float64array.html It takes some time before DumpRenderTree.exe quits after reporitng #EOF.
Created attachment 417800 [details] Patch
Comment on attachment 417800 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=417800&action=review > Tools/ChangeLog:9 > + (runTest): Reset preferences after loading the empty page because Is there any history of this line is here? I remember that we adjusted some of these before for other reasons, maybe this very one, but am not in front of a large enough screen to check now.
r177542 and r177613 changed Windows DRT to align with Mac DRT. r42056 changed Mac DRT. > * DumpRenderTree/mac/DumpRenderTree.mm: > (runTest): Added an additional call to resetWebViewToConsistentStateBeforeTesting just > before loading an empty page. This prevents extra policy delegate calls from being logged.
Created attachment 417859 [details] Patch
Making Windows DRT more like Mac one is reasonable. I've been thinking of recent changes like r267860, r256232, r244668. Looks like the latest patch breaks a couple tests on Mac.
(In reply to Alexey Proskuryakov from comment #6) > Making Windows DRT more like Mac one is reasonable. I've been thinking of > recent changes like r267860, r256232, r244668. IIUC those changes, my patch is irrelevant to them. > Looks like the latest patch breaks a couple tests on Mac. Oh no. Here is the callstack of the assertion failure of accessibility/add-children-pseudo-element.html and accessibility/svg-shape-labelled.html. ASSERTION FAILED: !createIfNecessary || rootSVGObject ./accessibility/AccessibilityRenderObject.cpp(3255) : WebCore::AccessibilitySVGRoot *WebCore::AccessibilityRenderObject::remoteSVGRootElement(WebCore::AccessibilityRenderObject::CreationChoice) const 1 0x10f9baa59 WTFCrash 2 0x12b679f0b WTFCrashWithInfo(int, char const*, char const*, int) 3 0x12de67d4f WebCore::AccessibilityRenderObject::remoteSVGRootElement(WebCore::AccessibilityRenderObject::CreationChoice) const 4 0x12de5b96a WebCore::AccessibilityRenderObject::detachRemoteSVGRoot() 5 0x12de5b8ee WebCore::AccessibilityRenderObject::detachRemoteParts(WebCore::AccessibilityDetachmentType) 6 0x12dddc51f WebCore::AXCoreObject::detach(WebCore::AccessibilityDetachmentType) 7 0x12dddc0be WebCore::AXObjectCache::~AXObjectCache() 8 0x12dddc7c5 WebCore::AXObjectCache::~AXObjectCache() 9 0x12e61a39b std::__1::default_delete<WebCore::AXObjectCache>::operator()(WebCore::AXObjectCache*) const 10 0x12e61a31f std::__1::unique_ptr<WebCore::AXObjectCache, std::__1::default_delete<WebCore::AXObjectCache> >::reset(WebCore::AXObjectCache*) 11 0x12e5b8897 std::__1::unique_ptr<WebCore::AXObjectCache, std::__1::default_delete<WebCore::AXObjectCache> >::operator=(std::nullptr_t) 12 0x12e5a953c WebCore::Document::clearAXObjectCache() 13 0x12e5b6b2c WebCore::Document::destroyRenderTree() 14 0x12e5b7137 WebCore::Document::willBeRemovedFromFrame() 15 0x12f4deef0 WebCore::Frame::setView(WTF::RefPtr<WebCore::FrameView, WTF::RawPtrTraits<WebCore::FrameView>, WTF::DefaultRefDerefTraits<WebCore::FrameView> >&&) 16 0x10b24f7bd WebFrameLoaderClient::transitionToCommittedForNewPage() 17 0x12f2bb2a8 WebCore::FrameLoader::transitionToCommitted(WebCore::CachedPage*) 18 0x12f2b9f00 WebCore::FrameLoader::commitProvisionalLoad() 19 0x12f22e12c WebCore::DocumentLoader::commitIfReady() 20 0x12f22e8c2 WebCore::DocumentLoader::finishedLoading() 21 0x12f23a47d WebCore::DocumentLoader::maybeLoadEmpty() 22 0x12f23a603 WebCore::DocumentLoader::startLoadingMainResource() 23 0x12f2e7535 WebCore::FrameLoader::continueLoadAfterNavigationPolicy(WebCore::ResourceRequest const&, WebCore::FormState*, WebCore::NavigationPolicyDecision, WebCore::AllowNavigationToInvalidURL)::$_11::operator()() 24 0x12f2e6e59 WTF::Detail::CallableWrapper<WebCore::FrameLoader::continueLoadAfterNavigationPolicy(WebCore::ResourceRequest const&, WebCore::FormState*, WebCore::NavigationPolicyDecision, WebCore::AllowNavigationToInvalidURL)::$_11, void>::call() 25 0x12b688c1a WTF::Function<void ()>::operator()() const 26 0x12b6f2eaa WTF::CompletionHandler<void ()>::operator()() 27 0x12f2b70a8 WebCore::FrameLoader::continueLoadAfterNavigationPolicy(WebCore::ResourceRequest const&, WebCore::FormState*, WebCore::NavigationPolicyDecision, WebCore::AllowNavigationToInvalidURL) 28 0x12f2e4344 WebCore::FrameLoader::loadWithDocumentLoader(WebCore::DocumentLoader*, WebCore::FrameLoadType, WTF::RefPtr<WebCore::FormState, WTF::RawPtrTraits<WebCore::FormState>, WTF::DefaultRefDerefTraits<WebCore::FormState> >&&, WebCore::AllowNavigationToInvalidURL, WTF::CompletionHandler<void ()>&&)::$_8::operator()(WebCore::ResourceRequest const&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision) 29 0x12f2e420c WTF::Detail::CallableWrapper<WebCore::FrameLoader::loadWithDocumentLoader(WebCore::DocumentLoader*, WebCore::FrameLoadType, WTF::RefPtr<WebCore::FormState, WTF::RawPtrTraits<WebCore::FormState>, WTF::DefaultRefDerefTraits<WebCore::FormState> >&&, WebCore::AllowNavigationToInvalidURL, WTF::CompletionHandler<void ()>&&)::$_8, void, WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision>::call(WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision) 30 0x12f3196e0 WTF::Function<void (WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision)>::operator()(WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision) const 31 0x12f30e1e5 WTF::CompletionHandler<void (WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision)>::operator()(WebCore::ResourceRequest&&, WTF::WeakPtr<WebCore::FormState, WTF::EmptyCounter>&&, WebCore::NavigationPolicyDecision) I just reordered loading an empty page and resetting prefs. It's weird. Anyway, I should look into it.
Comment on attachment 417859 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=417859&action=review > Tools/DumpRenderTree/mac/DumpRenderTree.mm:2042 > + // Reset preferences after loading an empty page. This comment needs to say *why* we do it after loading an empty page. Just like the one on Windows does. > Tools/DumpRenderTree/win/DumpRenderTree.cpp:1343 > + // Reset preferences after loading an empty page because it takes a long time for a large page. I think the use of "it" here makes this hard to understand. I would say "because changing some settings is very slow if there is a large page already loaded."
<rdar://problem/73558724>
r274407 (Bug 223109) fixed this bug. *** This bug has been marked as a duplicate of bug 223109 ***