To reproduce, see attached test case. This is a regression caused by r36954, which enabled certain constructors to be cached on the Window, as they should be. Unfortunately, this conflicts with a pre-existing issue in WebCore - the Window object is not properly replaced/cleared when transitioning from a temporary document created before loading to an actual one. The attached test case checks both the pre-existing issue, and its new manifestation.
Created attachment 24523 [details] test case
<rdar://problem/6303355>
In fact, this "pre-existing issue" is expected behavior, see <http://trac.webkit.org/changeset/25783/trunk/WebCore/loader/FrameLoader.cpp>. The attached test is faulty, as the way logging is done affects its results. The problem with XMLHttpRequest being broken remains.
Created attachment 28175 [details] proposed fix
Have you tested whether this creates memory leaks? It seems like the JSGlobalObject holds on to the JSImageConstructor, which now mark()s the JSGlobalObject...
Ignore my previous comment. I forgot that we use mark-and-sweep.
In what cases are we replacing the document but not the window object. Ideally, these should be one-to-one now.
Comment on attachment 28175 [details] proposed fix r=me I'm slightly worried since it would be insecure to re-use these JavaScript objects with a new document with a different security origin. But I guess we have tests to cover that possibility and they are not re-used in that bad way.
Sam, one case where we must replace only the document is in r25783.
Committed <http://trac.webkit.org/changeset/41732>. > I'm slightly worried since it would be insecure to re-use these JavaScript > objects with a new document with a different security origin. My understanding is that this patch doesn't make security weaker, because the only transition that ever happens is from about:blank.