Summary: | Particularly constructed WebFrames can try to access a null HistoryItem | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brady Eidson <beidson> | ||||||
Component: | Page Loading | Assignee: | Nobody <webkit-unassigned> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | aroben, fishd, plaes, webkit.review.bot | ||||||
Priority: | P2 | Keywords: | InRadar | ||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | All | ||||||||
OS: | OS X 10.5 | ||||||||
Attachments: |
|
Description
Brady Eidson
2010-02-17 16:41:27 PST
Created attachment 48947 [details]
Proposed fix, layout test, and Mac-only DRT changes.
Attachment 48947 [details] did not build on qt: Build output: http://webkit-commit-queue.appspot.com/results/279146 I don't understand how the Qt drt build wasn't already broken. None of the LayoutTestController methods that take JSStringRefs seem to be implemented for Qt, how are they linking at all. A review on the patch would still be appreciated while I try to figure out how to keep qt building... (In reply to comment #3) > I don't understand how the Qt drt build wasn't already broken. None of the > LayoutTestController methods that take JSStringRefs seem to be implemented for > Qt, how are they linking at all. > > A review on the patch would still be appreciated while I try to figure out how > to keep qt building... Qt has its own implementation of LayoutTestController. It doesn't use the cross-platform one the rest of the ports use. Landed in http://trac.webkit.org/changeset/54966 *** Bug 34905 has been marked as a duplicate of this bug. *** FYI, it looks like Tony attached a test case to bug 34905 for this crash that just uses an iframe. I saw that last night, and hope to adapt it to a new layout test when I have "spare cycles" Created attachment 49140 [details] Javascript test case > All known cases seem to be using the Mac or (Apple)Windows API's [WebFrame > loadData:] or [WebView initWithCoder:] which populate a WebFrame upon creation > with content but never actually navigating it. I was looking into a separate crash recently and noticed that this also fixes it. You don't need to use WebKit APIs to trigger this; another case is if you open an empty window and then document.write() into it. I've attached the file I had been testing with. (It appears that WebKit also doesn't follow what the standard says with regard to inserting history entries on document.open(). See 3.5.1. It looks like currently the type and replace arguments are ignored and no history modifications take place? Could be wrong about that --- only just started navigating the codebase.) (In reply to comment #9) > I was looking into a separate crash recently and noticed that this also fixes > it. You don't need to use WebKit APIs to trigger this; another case is if you > open an empty window and then document.write() into it. I've attached the file > I had been testing with. Thanks David, see the comments right above yours - this alternate way to crash was discovered after the fix and API test for this bug landed. > (It appears that WebKit also doesn't follow what the standard says with regard > to inserting history entries on document.open(). See 3.5.1. It looks like > currently the type and replace arguments are ignored and no history > modifications take place? Could be wrong about that --- only just started > navigating the codebase.) That seems completely orthogonal to this bug. If you think something's wrong, please file a bugzilla with: -A test case -What you think expected behavior should be (and how it differs from real behavior) -What other browsers do. |