* SUMMARY Assertion when quickly navigating back/forward. * STEPS TO REPRODUCE 1. Load <http://daringfireball.net> 2. Click a link to any article (off site) 3. Rapidly go back/forward => ASSERT eventually ASSERTION FAILED: m_uncommittedState.state == State::Committed Source/WebKit2/UIProcess/PageLoadState.cpp(289) : void WebKit::PageLoadState::didFinishLoad(const Transaction::Token &) 1 0x10b270e00 WTFCrash 2 0x10d241d43 WebKit::PageLoadState::didFinishLoad(WebKit::PageLoadState::Transaction::Token const&) 3 0x10d6f2624 WebKit::WebPageProxy::didFinishLoadForFrame(unsigned long long, unsigned long long, WebKit::UserData const&) 4 0x10d78f069 void IPC::callMemberFunctionImpl<WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(unsigned long long, unsigned long long, WebKit::UserData const&), std::__1::tuple<unsigned long long, unsigned long long, WebKit::UserData>, 0ul, 1ul, 2ul>(WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(unsigned long long, unsigned long long, WebKit::UserData const&), std::__1::tuple<unsigned long long, unsigned long long, WebKit::UserData>&&, std::index_sequence<0ul, 1ul, 2ul>) 5 0x10d78eea8 void IPC::callMemberFunction<WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(unsigned long long, unsigned long long, WebKit::UserData const&), std::__1::tuple<unsigned long long, unsigned long long, WebKit::UserData>, std::make_index_sequence<3ul> >(std::__1::tuple<unsigned long long, unsigned long long, WebKit::UserData>&&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(unsigned long long, unsigned long long, WebKit::UserData const&)) 6 0x10d76e696 void IPC::handleMessage<Messages::WebPageProxy::DidFinishLoadForFrame, WebKit::WebPageProxy, void (WebKit::WebPageProxy::*)(unsigned long long, unsigned long long, WebKit::UserData const&)>(IPC::MessageDecoder&, WebKit::WebPageProxy*, void (WebKit::WebPageProxy::*)(unsigned long long, unsigned long long, WebKit::UserData const&)) 7 0x10d765df2 WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&) 8 0x10d768c77 non-virtual thunk to WebKit::WebPageProxy::didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&) 9 0x10d17f48d IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::MessageDecoder&) 10 0x10d04c897 WebKit::ChildProcessProxy::dispatchMessage(IPC::Connection&, IPC::MessageDecoder&) 11 0x10d83779a WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&) 12 0x10d837897 non-virtual thunk to WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::MessageDecoder&) 13 0x10d059063 IPC::Connection::dispatchMessage(IPC::MessageDecoder&) 14 0x10d051040 IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::MessageDecoder, std::__1::default_delete<IPC::MessageDecoder> >) 15 0x10d058e3f IPC::Connection::dispatchOneMessage() 16 0x10d06dca2 WTF::FunctionWrapper<void (IPC::Connection::*)()>::operator()(IPC::Connection*) 17 0x10d06dc25 WTF::BoundFunctionImpl<WTF::FunctionWrapper<void (IPC::Connection::*)()>, void (IPC::Connection*)>::operator()() 18 0x10d06d122 WTF::Function<void ()>::operator()() const 19 0x10d06d09c std::__1::__function::__func<WTF::Function<void ()>, std::__1::allocator<WTF::Function<void ()> >, void ()>::operator()() 20 0x10b21d3ca std::__1::function<void ()>::operator()() const 21 0x10b2aac42 WTF::RunLoop::performWork() 22 0x10b2ac054 WTF::RunLoop::performWork(void*) 23 0x7fff87d14381 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 24 0x7fff87d0650d __CFRunLoopDoSources0 25 0x7fff87d05b3f __CFRunLoopRun 26 0x7fff87d05558 CFRunLoopRunSpecific 27 0x7fff8d139b4f RunCurrentEventLoopInMode 28 0x7fff8d1398ca ReceiveNextEventCommon 29 0x7fff8d13970b _BlockUntilNextEventMatchingListInModeWithFilter 30 0x7fff8e77c0ad _DPSNextEvent 31 0x7fff8e77b6b0 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
Seems like a good thing to fix, who knows what the consequences of an incorrect PageLoadState are.
I've start to look at this issue.
I'm not able to reproduce this issue in my system(OSX 10.8.5) until now.
Created attachment 257552 [details] Patch
Comment on attachment 257552 [details] Patch This feels like a much larger change that the diff might suggest. Do all the tests pass in WK2 and Mac WK1? Is a test for the failure not possible?
I've (In reply to comment #5) > Comment on attachment 257552 [details] > Patch > > This feels like a much larger change that the diff might suggest. > > Do all the tests pass in WK2 and Mac WK1? > > Is a test for the failure not possible? I've tested this patch in WK2 GTK port. There is no any other regression in WK2 GTK port.
Comment on attachment 257552 [details] Patch Could you please add a regression test for this?
Comment on attachment 257552 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=257552&action=review > Source/WebCore/ChangeLog:9 > + provisitonal item in history when we load page from page cache. "provisional"
Created attachment 276306 [details] Patch
(In reply to comment #8) > Comment on attachment 257552 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=257552&action=review > > > Source/WebCore/ChangeLog:9 > > + provisitonal item in history when we load page from page cache. > > "provisional" Done
Comment on attachment 276306 [details] Patch Attachment 276306 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/1146974 New failing tests: http/tests/loading/main-resource-delegates-on-back-navigation.html
Created attachment 276309 [details] Archive of layout-test-results from ews101 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews101 Port: mac-yosemite Platform: Mac OS X 10.10.5
Comment on attachment 276306 [details] Patch Attachment 276306 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/1146982 New failing tests: http/tests/loading/main-resource-delegates-on-back-navigation.html
Created attachment 276310 [details] Archive of layout-test-results from ews106 for mac-yosemite-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews106 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Comment on attachment 276306 [details] Patch Attachment 276306 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/1146985 New failing tests: http/tests/loading/main-resource-delegates-on-back-navigation.html
Created attachment 276311 [details] Archive of layout-test-results from ews113 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews113 Port: mac-yosemite Platform: Mac OS X 10.10.5
Comment on attachment 276306 [details] Patch Attachment 276306 [details] did not pass ios-sim-ews (ios-simulator-wk2): Output: http://webkit-queues.webkit.org/results/1146988 New failing tests: http/tests/loading/main-resource-delegates-on-back-navigation.html
Created attachment 276312 [details] Archive of layout-test-results from ews122 for ios-simulator-wk2 The attached test failures were seen while running run-webkit-tests on the ios-sim-ews. Bot: ews122 Port: ios-simulator-wk2 Platform: Mac OS X 10.10.5
Comment on attachment 276306 [details] Patch This patch is causing the http/tests/loading/main-resource-delegates-on-back-navigation.html to fail. Please run the test locally and figure out why it’s failing.
(In reply to comment #19) > Comment on attachment 276306 [details] > Patch > > This patch is causing the > http/tests/loading/main-resource-delegates-on-back-navigation.html to fail. > Please run the test locally and figure out why it’s failing. Sure, I will investigate it.
<rdar://problem/54779098>