Bug 109485 – Load event fires too early with threaded HTML parser (take 2)

• Component: New Bugs
• Status: RESOLVED FIXED

[Adam Barth]

Load event fires too early with threaded HTML parser (take 2)

[Adam Barth]

Created attachment 187661 [details]
Patch

[Eric Seidel (no email)]

Comment on attachment 187661 [details]
Patch

Fantastic.

[WebKit Review Bot]

Comment on attachment 187661 [details]
Patch

Rejecting attachment 187661 [details] from commit-queue.

New failing tests:
fast/frames/iframe-access-screen-of-deleted.html
platform/chromium/virtual/softwarecompositing/iframes/remove-iframe-crash.html
http/tests/misc/xslt-bad-import.html
compositing/iframes/remove-iframe-crash.html
Full output: http://queues.webkit.org/results/16493415

[WebKit Review Bot]

Comment on attachment 187661 [details]
Patch

Attachment 187661 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/16491453

New failing tests:
fast/frames/iframe-access-screen-of-deleted.html
platform/chromium/virtual/softwarecompositing/iframes/remove-iframe-crash.html
http/tests/misc/xslt-bad-import.html
compositing/iframes/remove-iframe-crash.html

[Adam Barth]

Created attachment 187706 [details]
Patch for landing

[Adam Barth]

Created attachment 187708 [details]
Patch for landing

[WebKit Review Bot]

Comment on attachment 187708 [details]
Patch for landing

Clearing flags on attachment: 187708

Committed r142555: <http://trac.webkit.org/changeset/142555>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Dima Gorbik]

For some reason this breaks fast/dom/window-load-crash.html for WK2. Do you have any ideas why this could this happen? (I guess we get a timeout when running this test)
Thanks!

[Benjamin Poulain]

(In reply to comment #9)
> For some reason this breaks fast/dom/window-load-crash.html for WK2. Do you have any ideas why this could this happen? (I guess we get a timeout when running this test)

(On the debug bots)

[Adam Barth]

Interesting.  I'll take a look in the morning.

[Thiago Marcos P. Santos]

I have the following tests asserting on the EFL WK2 Debug bot after this patch:

fast/dom/window-load-crash.html
fast/frames/seamless/seamless-hyperlink-named.html
fast/frames/seamless/seamless-hyperlink.html

The backtrace is the same for all of them:

crash log for WebKitTestRunner (pid 680):
STDOUT: <empty>
STDERR: ASSERTION FAILED: m_loadState == LoadStateFinished
STDERR: /home/buildslave-1/webkit-buildslave/efl-linux-64-debug-wk2/build/Source/WebKit2/UIProcess/WebFrameProxy.cpp(132) : void WebKit::WebFrameProxy::didStartProvisionalLoad(const WTF::String&)
STDERR: 1   0x7f31f9c6e018 WebKit::WebFrameProxy::didStartProvisionalLoad(WTF::String const&)
STDERR: 2   0x7f31f9c8e4f0 WebKit::WebPageProxy::didStartProvisionalLoadForFrame(unsigned long, WTF::String const&, WTF::String const&, CoreIPC::MessageDecoder&)
STDERR: 3   0x7f31f9e7d179 void CoreIPC::callMemberFunction<WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(unsigned long, WTF::String const&, WTF::String const&, CoreIPC::MessageDecoder&), unsigned long, WTF::String, WTF::String>(CoreIPC::Arguments3<unsigned long, WTF::String, WTF::String> const&, CoreIPC::MessageDecoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(unsigned long, WTF::String const&, WTF::String const&, CoreIPC::MessageDecoder&))
STDERR: 4   0x7f31f9e793fc void CoreIPC::handleMessageVariadic<Messages::WebPageProxy::DidStartProvisionalLoadForFrame, WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(unsigned long, WTF::String const&, WTF::String const&, CoreIPC::MessageDecoder&)>(CoreIPC::MessageDecoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(unsigned long, WTF::String const&, WTF::String const&, CoreIPC::MessageDecoder&))
STDERR: 5   0x7f31f9e736f7 WebKit::WebPageProxy::didReceiveMessage(CoreIPC::Connection*, CoreIPC::MessageDecoder&)
STDERR: 6   0x7f31f9bbd242 CoreIPC::MessageReceiverMap::dispatchMessage(CoreIPC::Connection*, CoreIPC::MessageDecoder&)
STDERR: 7   0x7f31f9bd3619 WebKit::ChildProcessProxy::dispatchMessage(CoreIPC::Connection*, CoreIPC::MessageDecoder&)
STDERR: 8   0x7f31f9ccd9c3 WebKit::WebProcessProxy::didReceiveMessage(CoreIPC::Connection*, CoreIPC::MessageDecoder&)
STDERR: 9   0x7f31f9baa377 CoreIPC::Connection::dispatchMessage(CoreIPC::MessageDecoder&)
STDERR: 10  0x7f31f9baa464 CoreIPC::Connection::dispatchMessage(WTF::PassOwnPtr<CoreIPC::MessageDecoder>)
STDERR: 11  0x7f31f9baa685 CoreIPC::Connection::dispatchOneMessage()
STDERR: 12  0x7f31f9bbc4ee WTF::FunctionWrapper<void (CoreIPC::Connection::*)()>::operator()(CoreIPC::Connection*)
STDERR: 13  0x7f31f9bbc046 WTF::BoundFunctionImpl<WTF::FunctionWrapper<void (CoreIPC::Connection::*)()>, void (CoreIPC::Connection*)>::operator()()
STDERR: 14  0x7f32019b7004 WTF::Function<void ()>::operator()() const
STDERR: 15  0x7f31fd615d23 WebCore::RunLoop::performWork()
STDERR: 16  0x7f31fe1abb36 WebCore::RunLoop::wakeUpEvent(void*, void*, unsigned int)
STDERR: 17  0x7f31f8fb56c1
STDERR: 18  0x7f31f8fb4601
STDERR: 19  0x7f31f8fb4b47 ecore_main_loop_begin
STDERR: 20  0x4363cb WTR::TestController::platformRunUntil(bool&, double)
STDERR: 21  0x420214 WTR::TestController::runUntil(bool&, WTR::TestController::TimeoutDuration)
STDERR: 22  0x427a09 WTR::TestInvocation::invoke()
STDERR: 23  0x41ff34 WTR::TestController::runTest(char const*)
STDERR: 24  0x42006d WTR::TestController::runTestingServerLoop()
STDERR: 25  0x420107 WTR::TestController::run()
STDERR: 26  0x41d7a5 WTR::TestController::TestController(int, char const**)
STDERR: 27  0x436566 main
STDERR: 28  0x7f31f7b1376d __libc_start_main
STDERR: 29  0x41c089
STDERR: ERROR: Thread name "com.apple.WebKit.ChildProcess.WatchDogQueue" is longer than 31 characters and will be truncated by Visual Studio
STDERR: /home/buildslave-1/webkit-buildslave/efl-linux-64-debug-wk2/build/Source/WTF/wtf/Threading.cpp(78) : WTF::ThreadIdentifier WTF::createThread(WTF::ThreadFunction, void*, const char*)

[Adam Barth]

Thanks.  Building apple-mac now.

[Eric Seidel (no email)]

Yes, I'm able to repro on WK2 Mac:
run-webkit-tests -2 --debug fast/dom/window-load-crash.html

[Adam Barth]

The ASSERT appears to be bogus.  I'll file a new bug with the fix.

[Adam Barth]

Patch in bug 109733