Bug 36464 - HistoryConroller::m_currentItem can sometimes be null for a fully loaded frame
: HistoryConroller::m_currentItem can sometimes be null for a fully loaded frame
Status: NEW
Product: WebKit
Classification: Unclassified
Component: History
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To: Darin Fisher (:fishd, Google)
:
Depends on: 38840
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-22 15:43 PDT by Darin Fisher (:fishd, Google)
Modified: 2010-05-11 03:23 PDT (History)
2 users (show)

See Also:


Attachments
testcase (395 bytes, text/html)
2010-03-22 15:46 PDT, Darin Fisher (:fishd, Google)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Fisher (:fishd, Google) 2010-03-22 15:43:18 PDT
HistoryConroller::m_currentItem can sometimes be null for a fully loaded frame

This should not be possible, and it causes the following problems:

1) Unable to save form and scrollbar state
2) Unable to support history.replaceState method

I'll attach a test case that shows at least one way for m_currentItem to be null.
Comment 1 Darin Fisher (:fishd, Google) 2010-03-22 15:46:26 PDT
Created attachment 51365 [details]
testcase
Comment 2 Jędrzej Nowacki 2010-05-11 03:23:02 PDT
Another testcase looks like that (Qt, C++ code):

QWebPage page;
page.mainFrame->setHtml("...");

Documentation of the QWebFrane::setHtml contains a note: "This method will not affect session or global history for the frame". As the setHtml doesn't affect a history it is really easy to assert/crash on a history opertions (for example pushState). It seems that we can't assume that m_currentItem or m_previousItem are always set after frame got loaded.

I'm linking the bug to 38840.