Bug 36443 – [chromium] Renderer crashes when navigating to a reference fragment in a frame that has no current HistoryItem.

• Component: WebKit API
• Status: RESOLVED FIXED

[Dave Moore]

1) Go to this page: http://www.fandango.com/hottubtimemachine_126387/movietimes?date= in tip of tree chromium.
2) Place cursor in zip code text field.

Sad tab appears

I ran the linux build and got the stack trace below. It looks like the problem is in the second frame at FrameLoaderClientImpl.cpp:591, where the return of currentItem() is NULL. 

This appears to be recent code, introduced into webkit here:
https://bugs.webkit.org/attachment.cgi?id=50758&action=prettypatch

#0  0x09257db6 in WTF::RefPtr<WebCore::SerializedScriptValue>::get (this=0x74)
    at third_party/WebKit/JavaScriptCore/wtf/RefPtr.h:58
#1  0x09257dce in WebCore::HistoryItem::stateObject (this=0x0)
    at third_party/WebKit/WebCore/history/HistoryItem.h:137
#2  0x09c1c31b in WebKit::FrameLoaderClientImpl::dispatchDidNavigateWithinPage
    (this=0xe82250c)
    at third_party/WebKit/WebKit/chromium/src/FrameLoaderClientImpl.cpp:591
#3  0x0925121b in WebCore::FrameLoader::loadInSameDocument(WebCore::KURL const&, WebCore::SerializedScriptValue*, bool) ()
#4  0x092514b3 in WebCore::FrameLoader::continueFragmentScrollAfterNavigationPolicy(WebCore::ResourceRequest const&, bool) ()
#5  0x092514e6 in WebCore::FrameLoader::callContinueFragmentScrollAfterNavigationPolicy(void*, WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>, bool) ()
#6  0x09263d9a in WebCore::PolicyCallback::call(bool) ()
#7  0x092648aa in WebCore::PolicyChecker::continueAfterNavigationPolicy(WebCore::PolicyAction) ()
#8  0x09c1b875 in WebKit::FrameLoaderClientImpl::dispatchDecidePolicyForNavigationAction (this=0xe82250c, 
    function=0x92646d6 <WebCore::PolicyChecker::continueAfterNavigationPolicy(WebCore::PolicyAction)>, action=..., request=..., formState=...)
    at third_party/WebKit/WebKit/chromium/src/FrameLoaderClientImpl.cpp:975
#9  0x09264dd4 in WebCore::PolicyChecker::checkNavigationPolicy(WebCore::Resourc---Type <return> to continue, or q <return> to quit---
eRequest const&, WebCore::DocumentLoader*, WTF::PassRefPtr<WebCore::FormState>, void (*)(void*, WebCore::ResourceRequest const&, WTF::PassRefPtr<WebCore::FormState>, bool), void*) ()
#10 0x0925556a in WebCore::FrameLoader::loadURL(WebCore::KURL const&, WebCore::String const&, WebCore::String const&, bool, WebCore::FrameLoadType, WTF::PassRefPtr<WebCore::Event>, WTF::PassRefPtr<WebCore::FormState>) ()
#11 0x09255afd in WebCore::FrameLoader::loadFrameRequest(WebCore::FrameLoadRequest const&, bool, bool, WTF::PassRefPtr<WebCore::Event>, WTF::PassRefPtr<WebCore::FormState>, WebCore::ReferrerPolicy) ()
#12 0x09255ec9 in WebCore::FrameLoader::urlSelected(WebCore::ResourceRequest const&, WebCore::String const&, WTF::PassRefPtr<WebCore::Event>, bool, bool, bool, WebCore::ReferrerPolicy) ()
#13 0x092560b6 in WebCore::FrameLoader::changeLocation(WebCore::KURL const&, WebCore::String const&, bool, bool, bool, bool) ()
#14 0x09268dbf in WebCore::RedirectScheduler::scheduleLocationChange(WebCore::String const&, WebCore::String const&, bool, bool, bool) ()
#15 0x094e98cf in WebCore::navigateIfAllowed(WebCore::Frame*, WebCore::KURL const&, bool, bool) ()
#16 0x09dd3925 in WebCore::V8Location::replaceCallback(v8::Arguments const&) ()
#17 0x08e8d19f in HandleApiCallHelper<false> (args=...)
    at v8/src/builtins.cc:904
#18 0x08e8d24a in Builtin_Impl_HandleApiCall (args=...)
    at v8/src/builtins.cc:921
---Type <return> to continue, or q <return> to quit---
#19 0x08e8d26f in Builtin_HandleApiCall (args=...) at v8/src/builtins.cc:920
#20 0xebc7238e in ?? ()
#21 0x00000003 in ?? ()

[Darin Fisher (:fishd, Google)]

Yeah, we've received a lot of reports of this crash:
http://code.google.com/p/chromium/issues/detail?id=38658

[Darin Fisher (:fishd, Google)]

Created attachment 51293 [details]
v1 patch

[Darin Fisher (:fishd, Google)]

Created attachment 51295 [details]
v2 patch (minus svn:eol-style on layout tests)

[Nate Chapin]

Comment on attachment 51295 [details]
v2 patch (minus svn:eol-style on layout tests)

LGTM

Re: the FIXME: Do we have any idea how currentItem is ending up null?  I'm assuming that it is a bug that script shenanigans like the ones in this layout test can cause it to become null?

[Darin Fisher (:fishd, Google)]

(In reply to comment #4)
> (From update of attachment 51295 [details])
> LGTM
> 
> Re: the FIXME: Do we have any idea how currentItem is ending up null?  I'm
> assuming that it is a bug that script shenanigans like the ones in this layout
> test can cause it to become null?

Yes, I plan on fixing cases that cause this to be null, but that will be done as a separate patch.  First things first:  fix the crash :-)

[Darin Fisher (:fishd, Google)]

Landed as http://trac.webkit.org/changeset/56346