document.open() erroneously returns void instead of the new Document
in other browsers (IE, FF, and Opera), document.open() returns the new Document, and you can write into it to generate content.
var d = document.open("text/html", "replace");
apparently, the html5 spec does not describe this behavior:
mozilla defines the form of document.open that returns a new document here (as a Netscape extension to the DOM):
Created attachment 15975 [details]
This test works in Firefox 2, but not in Opera. Haven't tried with IE yet.
This test fails in IE, too.
Alexey, your test case does not match the one in comment #0. If you try that you should see that FF2, IE6 and Opera9 all generate a page with the text "foo"
Created attachment 15992 [details]
test case (as originally reported)
(In reply to comment #3)
> Alexey, your test case does not match the one in comment #0.
Do you mean that the second parameter is true instead of "replace" in my test case? Indeed, I mistakenly used he linked Mozilla IDL to check the type - but it doesn't matter anyway, as the behavior WRT this issue is the same AFAICT.
It seems that the main difference between our test cases is that the code runs during parsing in the first one, and after parsing has finished in the second one.
Ah, yes... It is interesting that the behavior varies depending on whether or not we are done parsing the main document.
Created attachment 25588 [details]
Note that parameters are currently ignored (except for checking their number, and forwarding to DOMWindow if necessary).
Comment on attachment 25588 [details]
This would ideally be one of the fancy new js-only tests... then again, ideally it would be easier (and more documented) to write a newer-fancy-js-only test. Sad that this has to be custom. But glad to see this fix!
(In reply to comment #8)
> This would ideally be one of the fancy new js-only tests...
Are you talking about js-test-pre.js and friends? I can think of many minor shortcomings, but not a single benefit - these tests are slower because of the need to load external subresources, they cannot be easily copied to another directory, they often need to be written in roundabout ways to convert a behavior check into a simple shouldBe().
Of course, fast/js is a special case, because the intention is to make those work from pure JS environment eventually.
Thanks for review!
Committed revision 38842.