[Webkit-unassigned] [Bug 35063] New: Particularly constructed WebFrames can try to access a null HistoryItem

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=35063

           Summary: Particularly constructed WebFrames can try to access a
                    null HistoryItem
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: All
        OS/Version: Mac OS X 10.5
            Status: NEW
          Keywords: InRadar
          Severity: Normal
          Priority: P2
         Component: Page Loading
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: beidson at apple.com


Starting with the changes for the history state object API, we do work to keep
history items chained together after navigations.

There are some cases where this can occur when there wasn't an "m_currentItem"
before a navigation took place.

All known cases seem to be using the Mac or (Apple)Windows API's [WebFrame
loadData:] or [WebView initWithCoder:] which populate a WebFrame upon creation
with content but never actually navigating it.

A subsequent intra-document navigation that attempts to chain together history
items will result in a null deref.

I initially tried to fix this by *ALWAYS* giving HistoryController an empty
m_currentItem at creation.  This resulted in many failing layout tests as the
null-ness of the current item seems to be a linchpin when deciding whether a
frame contains the "initial empty document" or has actually been navigated
somewhere, and changing this throws off the back forward list in many tests in
many different ways.

Cleaning that up is part of a much greater FrameLoader refactoring task.  For
now, I'll be adding a proposed fix that simply does a null-check and early
return in the known fragment identifier scrolling case.  Note that there are a
few other "m_currentItem" null checks in HistoryController and - while
FrameLoader should probably be reworked so they aren't necessary - it seems
like this one was one that has simply stayed hidden until we started to see
some crashes with particular API usage.

The patch will also continue - for now Mac-only - DRT changes that twiddle this
crash with the very specific WebKit API usage needed.

In radar as <rdar://problem/7638892>

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.