Bug 14968 – document.open() erroneously returns void instead of the new Document

• Component: DOM
• Status: RESOLVED FIXED

[Darin Fisher (:fishd, Google)]

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.

example:

  var d = document.open("text/html", "replace");
  d.write("foo");
  d.close();

apparently, the html5 spec does not describe this behavior:
http://www.whatwg.org/specs/web-apps/current-work/#htmldocument

mozilla defines the form of document.open that returns a new document here (as a Netscape extension to the DOM):
http://lxr.mozilla.org/seamonkey/source/dom/public/idl/html/nsIDOMNSHTMLDocument.idl

[Alexey Proskuryakov]

Created attachment 15975 [details]
test case

This test works in Firefox 2, but not in Opera. Haven't tried with IE yet.

[Alexey Proskuryakov]

This test fails in IE, too.

[Darin Fisher (:fishd, Google)]

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"

[Darin Fisher (:fishd, Google)]

Created attachment 15992 [details]
test case (as originally reported)

[Alexey Proskuryakov]

(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.

[Darin Fisher (:fishd, Google)]

Ah, yes...  It is interesting that the behavior varies depending on whether or not we are done parsing the main document.

[Alexey Proskuryakov]

Created attachment 25588 [details]
proposed fix

Note that parameters are currently ignored (except for checking their number, and forwarding to DOMWindow if necessary).

[Eric Seidel (no email)]

Comment on attachment 25588 [details]
proposed fix

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!

[Alexey Proskuryakov]

(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!

[Alexey Proskuryakov]

Committed revision 38842.