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
: WebKit
History
: 528+ (Nightly build)
: All All
: P2 Normal
Assigned To:
:
:
: 38840
:
  Show dependency treegraph
 
Reported: 2010-03-22 15:43 PST by
Modified: 2010-05-11 03:23 PST (History)


Attachments
testcase (395 bytes, text/html)
2010-03-22 15:46 PST, 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 From 2010-03-22 15:43:18 PST
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 From 2010-03-22 15:46:26 PST -------
Created an attachment (id=51365) [details]
testcase
------- Comment #2 From 2010-05-11 03:23:02 PST -------
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.