Bug 53856 - Regression / Crash(Chromium): Navigating to the initial page doesn't work and crashes Chromium
Summary: Regression / Crash(Chromium): Navigating to the initial page doesn't work and...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: History (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC Windows Vista
: P2 Normal
Assignee: Nobody
URL: https://bugs.webkit.org/attachment.cg...
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-05 08:44 PST by Peter Beverloo
Modified: 2012-09-06 06:24 PDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Beverloo 2011-02-05 08:44:50 PST
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
Comment 1 Mihai Parparita 2011-02-05 09:05:21 PST
The crash in recursiveSetProvisionalItem looks similar to bug 52819 (the fix for which your Chromium build doesn't have).
Comment 2 Darth 2011-02-07 14:48:55 PST
This might be a dupe of Bug 53708 which in turn got fixed in the same change list as bug 52819
Comment 3 Charles Reis 2011-02-07 14:52:13 PST
(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.
Comment 4 Darth 2011-02-07 15:00:32 PST
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.
Comment 5 Adam Barth 2011-03-23 00:28:31 PDT
@creis are you still planning to look at this issue?
Comment 6 Charles Reis 2011-03-23 09:31:32 PDT
(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.
Comment 7 Peter Beverloo 2012-09-06 06:24:51 PDT
Closing this, as I can't reproduce it anymore :-).