Summary: | REGRESSION: ASSERTION FAILED: m_webFrame->_private->currentItem (WebFrameLoaderClient::restoreScrollPositionAndViewState()) | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | David Kilzer (:ddkilzer) <ddkilzer> | ||||||
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | NEW --- | ||||||||
Severity: | Major | CC: | andersca, ap, beidson, catfish.man, emacemac7, joost, mitz, scss.dev1, vidavera | ||||||
Priority: | P1 | Keywords: | InRadar, NeedsReduction, Regression | ||||||
Version: | 420+ | ||||||||
Hardware: | Mac | ||||||||
OS: | OS X 10.4 | ||||||||
Attachments: |
|
Description
David Kilzer (:ddkilzer)
2006-11-30 22:09:33 PST
Created attachment 11702 [details]
Test webarchive (will crash debug builds)
Webarchive file used to reproduce the assertion failure.
Created attachment 12537 [details]
Test App
This attachment is a tiny app that demonstrates the crash. It just loads an empty html file, and then when you click reload (attached to -reload:) it will crash. The executable is set to use the webkit from a nightly in /Applications.
According to David Smith, this crashes in release builds. I can totally repro this using the test app. I don't have alot of time to look at it at the moment, but this is high on my priority list. It's quite easy to see from the assertion that it'll crash a release build, as well ;) Every single time! If this crashes release builds as well, this isn't a regression now is it? :) (In reply to comment #6) > If this crashes release builds as well, this isn't a regression now is it? :) > "release builds" in this context means "TOT builds using the release build style", not "shipping builds". I could not reproduce the bug with the test app, although it's still reproducible with the webarchive. This regressed in http://trac.webkit.org/projects/webkit/changeset/14920 The attached webarchive doesn't crash nightly r21059 for me. A comment after the failing assertion casts some doubt over its validity: // 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! |