Bug 16952
| Summary: | Reproducible assertion failure in FrameLoader::restoreScrollPositionAndViewState() (m_currentHistoryItem) | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | mitz |
| Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | Normal | CC: | ahmad.saleem792, tevaum |
| Priority: | P2 | Keywords: | HasReduction, InRadar |
| Version: | 528+ (Nightly build) | ||
| Hardware: | Mac | ||
| OS: | OS X 10.5 | ||
| URL: | http://www.leviahon.co.il/article.php?id=637 | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=252944 | ||
mitz
See also bug 13684 <rdar://problem/5203036>.
ASSERTION FAILED: m_currentHistoryItem
(WebCore/loader/FrameLoader.cpp:3916 void WebCore::FrameLoader::restoreScrollPositionAndViewState())
Steps to reproduce:
1) Go to the URL.
2) Click the black&white photo.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
mitz
Reduction: enter the following in the address bar:
javascript: window.open().location.reload()
Mark Rowe (bdash)
What's the impact of this in a release build?
Mark Rowe (bdash)
Just looked at the code:
ASSERT(m_currentHistoryItem);
// FIXME: As the ASSERT attests, it seems we should always have a currentItem here.
// One counterexample is <rdar://problem/4917290>
// For now, to cover this issue in release builds, there is no technical harm to returning
// early and from a user standpoint - as in the above radar - the previous page load failed
// so there *is* no scroll or view state to restore!
if (!m_currentHistoryItem)
return;
In a release build this would seem to be harmless.
Mark Rowe (bdash)
<rdar://problem/5697153>
Ahmad Saleem
*** This bug has been marked as a duplicate of bug 252944 ***