WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 252944
36464
HistoryConroller::m_currentItem can sometimes be null for a fully loaded frame
https://bugs.webkit.org/show_bug.cgi?id=36464
Summary
HistoryConroller::m_currentItem can sometimes be null for a fully loaded frame
Darin Fisher (:fishd, Google)
Reported
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.
Attachments
testcase
(395 bytes, text/html)
2010-03-22 15:46 PDT
,
Darin Fisher (:fishd, Google)
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
Darin Fisher (:fishd, Google)
Comment 1
2010-03-22 15:46:26 PDT
Created
attachment 51365
[details]
testcase
Jędrzej Nowacki
Comment 2
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.
Ahmad Saleem
Comment 3
2023-10-03 10:50:49 PDT
*** This bug has been marked as a duplicate of
bug 252944
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug