53856 2011-02-05 08:44:50 -0800 Regression / Crash(Chromium): Navigating to the initial page doesn't work and crashes Chromium 2012-09-06 06:24:51 -0700 1 1 1 Unclassified WebKit History 528+ (Nightly build) PC Windows Vista RESOLVED INVALID https://bugs.webkit.org/attachment.cgi?id=58498 P2 Normal --- 1 peter webkit-unassigned abarth creis dglazkov fishd mihaip pablo.platt priyajeet.hora oldest_to_newest 346149 0 peter 2011-02-05 08:44:50 -0800 The initial testcase from bug 40451 does not navigate back to the initial page: https://bugs.webkit.org/attachment.cgi?id=58425&action=edit The reduced test-case (v2) doesn't either, but doesn't do so in Firefox and/or Opera either. Reproduction steps: 1. Open the test-case. 2. Click on "Artists" in the iframe. 3. Navigate backwards. Behavior WebKit nightly (r77737): It's impossible to go back to the initial content without refreshing. Opera and Firefox work fine here. Behavior Chromium (73930): Same as above, with one addition: when navigating forward again, it crashes on Windows Vista SP2 (64-bit) with the following call stack: > chrome.dll!WebCore::HistoryController::recursiveSetProvisionalItem(WebCore::HistoryItem * item=0x043036e0, WebCore::HistoryItem * fromItem=0x07629320, WebCore::FrameLoadType type=FrameLoadTypeIndexedBackForward) Line 629 C++ chrome.dll!WebCore::HistoryController::goToItem(WebCore::HistoryItem * targetItem=0x043036e0, WebCore::FrameLoadType type=FrameLoadTypeIndexedBackForward) Line 250 C++ chrome.dll!WebKit::WebFrameImpl::loadHistoryItem(const WebKit::WebHistoryItem & item={...}) Line 908 C++ chrome.dll!RenderView::OnNavigate(const ViewMsg_Navigate_Params & params={...}) Line 1437 + 0x24 bytes C++ chrome.dll!IPC::MessageWithTuple<Tuple1<ViewMsg_Navigate_Params> >::Dispatch<RenderView,RenderView,void (__thiscall RenderView::*)(ViewMsg_Navigate_Params const &)>(const IPC::Message * msg=0x04efca90, RenderView * obj=0x04703400, RenderView * sender=0x04703400, void (const ViewMsg_Navigate_Params &)* func=0x5dcb6d00) Line 934 C++ chrome.dll!RenderView::OnMessageReceived(const IPC::Message & message={...}) Line 987 + 0x1e bytes C++ chrome.dll!MessageRouter::RouteMessage(const IPC::Message & msg={...}) Line 46 + 0xa bytes C++ chrome.dll!MessageRouter::OnMessageReceived(const IPC::Message & msg={...}) Line 38 + 0x5 bytes C++ chrome.dll!ChildThread::OnMessageReceived(const IPC::Message & msg={...}) Line 168 + 0xb bytes C++ chrome.dll!RunnableMethod<SafeBrowsingService,void (__thiscall SafeBrowsingService::*)(SafeBrowsingService::UnsafeResource const &),Tuple1<SafeBrowsingService::UnsafeResource> >::Run() Line 331 + 0xf bytes C++ chrome.dll!MessageLoop::RunTask(Task * task=0x04efca80) Line 363 C++ chrome.dll!MessageLoop::DoWork() Line 564 + 0x8 bytes C++ chrome.dll!base::MessagePumpForUI::DoRunLoop() Line 202 C++ chrome.dll!base::MessagePumpWin::Run(base::MessagePump::Delegate * delegate=0x0492fabc) Line 79 + 0x42 bytes C++ chrome.dll!MessageLoop::RunInternal() Line 337 + 0xb bytes C++ chrome.dll!MessageLoop::Run() Line 235 C++ chrome.dll!base::Thread::Run(MessageLoop * message_loop=0x0492fabc) Line 129 C++ chrome.dll!base::Thread::ThreadMain() Line 167 C++ chrome.dll!base::`anonymous namespace'::ThreadFunc(void * params=0x042f1a98) Line 38 C++ This is reproducible with the reduced test-case as well: https://bugs.webkit.org/attachment.cgi?id=58498 346151 1 mihaip 2011-02-05 09:05:21 -0800 The crash in recursiveSetProvisionalItem looks similar to bug 52819 (the fix for which your Chromium build doesn't have). 346820 2 priyajeet.hora 2011-02-07 14:48:55 -0800 This might be a dupe of Bug 53708 which in turn got fixed in the same change list as bug 52819 346831 3 creis 2011-02-07 14:52:13 -0800 (In reply to comment #2) > This might be a dupe of Bug 53708 which in turn got fixed in the same change list as bug 52819 I believe this bug (minus the crash) is valid. Even after the patch for bug 52819, I can confirm that going back in the test case has no visual effect, making it so you can't get back to the initial page. It might have something to do with provisional items for hash navigations. I can take a look later this week. 346841 4 priyajeet.hora 2011-02-07 15:00:32 -0800 Really unsure if this bug is the same area as Bug 44228. Maybe you can take a look at that too if you have time :P It involves an iframe to maintain it's state when parent page is refreshed via browser. Because with history entries now being added properly with iframe navigation, reverting it to its original src, basically signifies that a parent page refresh == all those history entries gone. 371998 5 abarth 2011-03-23 00:28:31 -0700 @creis are you still planning to look at this issue? 372194 6 creis 2011-03-23 09:31:32 -0700 (In reply to comment #5) > @creis are you still planning to look at this issue? Sorry, I got pulled away on a few other issues. I probably won't be able to get to it right away if someone else wants to take a look, but I'll find time for it if not. 713235 7 peter 2012-09-06 06:24:51 -0700 Closing this, as I can't reproduce it anymore :-).