Bug 35063

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>