I'll attach LayoutTests shortly (They are also hosted at <http://crypto.stanford.edu/~abarth/research/webkit/jstests/>). Compare their behavior in WebKit to their behavior in Firefox and IE7.
Created attachment 18408 [details]
LayoutTests for these issues
Attached are some layout tests for these issues. These layout tests do not test for security, just for correctness. (Also, they might need to be tweaked to run correctly in DRT.)
See also: bug 9706.
See also bug 17367 and bug 17368.
Also see http://code.google.com/p/chromium/issues/detail?id=12161
Chrome has a P1 crashing bug around this. In cases where the script url constructs a document that initiates subresource loads as follows...
var doc = theFrame.document;
I have a patch addresses both the crash and the correctness issue... the constructed document should take precedence of the script's return value in this case (IE and FF do that).
Created attachment 30975 [details]
Here's the patch mentioned in the previous comment.
The crash I'm seeing is because the Document (and relatives) is being deleted, but resource loads are still pending. The 'fix' for that in here feels hacky. Seems like stopAllLoaders() should have taken care of things?
The fix for he correctness issue feels more correct to me.
This really feels like it should be two patches:
1) A patch to fix the correctness issue (with a LayoutTest showing the different behavior).
2) A patch to fix the crasher (also with a LayoutTest showing the crasher is gone).
(In reply to comment #7)
> This really feels like it should be two patches:
> crasher fix
I'm not real happy with this change. Any loader gurus out there see a more appropriate answer?
A symptom of the problem is that after calling stopAllLoaders(), the existing docs DocLoader->m_requestCount field has not gone to zero. The code that follows the stop call causes the existing doc to get blown away. The assertion in DocLoader's dtor fires at this point (ASSERT(m_requestCount == 0). At some later point, when those still active requests make progress of some kind, chrome crashes.
Should stopAllLoaders() also be responsible for terminating these requests too or not? If the intent was that it should terminate these requests too... i can make a change in there to ensure that it does so. Its just not clear to me if that is the intent of this method?
The crash is specific to chrome (perhaps browsers employing v8 more specifically). With safari (jsc), the sequence of events is different. I haven't drilled into where things are different just yet. I do know that if the pending requests are killed... crash fixed.
See bug 26230
I split that off for the chrome specific crasher instead of continuing to hijack this general issue for that specific one.
Also the stab at support for respecting programatically generate documents (in patch 12161.1.txt) seems like a good start... but its not sufficient... layout/rendering ceases immediate after the first frame to employ that technique. So we still have botched pages. I'm dropping that to focus on the blocking crasher.