Bug 36464 - HistoryConroller::m_currentItem can sometimes be null for a fully loaded frame
Summary: HistoryConroller::m_currentItem can sometimes be null for a fully loaded frame
Status: RESOLVED DUPLICATE of bug 252944
Alias: None
Product: WebKit
Classification: Unclassified
Component: History (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Darin Fisher (:fishd, Google)
URL:
Keywords:
Depends on: 38840
Blocks:
  Show dependency tree / graph
 
Reported: 2010-03-22 15:43 PDT by Darin Fisher (:fishd, Google)
Modified: 2023-10-03 10:50 PDT (History)
3 users (show)

See Also:

Attachments
testcase (395 bytes, text/html)
2010-03-22 15:46 PDT, Darin Fisher (:fishd, Google) 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

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.
Comment 3 Ahmad Saleem 2023-10-03 10:50:49 PDT 

*** This bug has been marked as a duplicate of bug 252944 ***