Bug 109485 - Load event fires too early with threaded HTML parser (take 2)
Summary: Load event fires too early with threaded HTML parser (take 2)
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adam Barth
URL:
Keywords:
Depends on: 109682
Blocks: 106127
  Show dependency treegraph
 
Reported: 2013-02-11 13:51 PST by Adam Barth
Modified: 2013-02-13 12:33 PST (History)
11 users (show)

See Also:


Attachments
Patch (2.32 KB, patch)
2013-02-11 13:52 PST, Adam Barth
no flags Details | Formatted Diff | Diff
Patch for landing (5.94 KB, patch)
2013-02-11 16:00 PST, Adam Barth
no flags Details | Formatted Diff | Diff
Patch for landing (6.44 KB, patch)
2013-02-11 16:02 PST, Adam Barth
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 2013-02-11 13:51:20 PST
Load event fires too early with threaded HTML parser (take 2)
Comment 1 Adam Barth 2013-02-11 13:52:55 PST
Created attachment 187661 [details]
Patch
Comment 2 Eric Seidel (no email) 2013-02-11 13:54:48 PST
Comment on attachment 187661 [details]
Patch

Fantastic.
Comment 3 WebKit Review Bot 2013-02-11 15:05:44 PST
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
Comment 4 WebKit Review Bot 2013-02-11 15:52:47 PST
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
Comment 5 Adam Barth 2013-02-11 16:00:09 PST
Created attachment 187706 [details]
Patch for landing
Comment 6 Adam Barth 2013-02-11 16:02:17 PST
Created attachment 187708 [details]
Patch for landing
Comment 7 WebKit Review Bot 2013-02-11 17:09:11 PST
Comment on attachment 187708 [details]
Patch for landing

Clearing flags on attachment: 187708

Committed r142555: <http://trac.webkit.org/changeset/142555>
Comment 8 WebKit Review Bot 2013-02-11 17:09:14 PST
All reviewed patches have been landed.  Closing bug.
Comment 9 Dima Gorbik 2013-02-12 20:16:24 PST
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!
Comment 10 Benjamin Poulain 2013-02-12 20:28:17 PST
(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)
Comment 11 Adam Barth 2013-02-12 21:11:53 PST
Interesting.  I'll take a look in the morning.
Comment 12 Thiago Marcos P. Santos 2013-02-13 04:59:44 PST
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*)
Comment 13 Adam Barth 2013-02-13 11:28:25 PST
Thanks.  Building apple-mac now.
Comment 14 Eric Seidel (no email) 2013-02-13 11:48:03 PST
Yes, I'm able to repro on WK2 Mac:
run-webkit-tests -2 --debug fast/dom/window-load-crash.html
Comment 15 Adam Barth 2013-02-13 12:29:25 PST
The ASSERT appears to be bogus.  I'll file a new bug with the fix.
Comment 16 Adam Barth 2013-02-13 12:33:55 PST
Patch in bug 109733