232698 - Allow javascript to create a new HTML document in memory

Status: RESOLVED DUPLICATE of bug 592827

(Core :: DOM: Core & HTML, defect)

Description

[Doron Rosenberg (IBM)]

Comment 1

[Boris Zbarsky [:bzbarsky]]

HTMLDOMImplementation?  What's that?

Comment 2

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Ah, I remember, that's why we decided not to support createHTMLDocument, it got
dropped from DOM Level 2. What we should rather do is to allow creation of
html-documents by passing an appropriate doctype to createDocument. While we're
there we should proably support creating xul, xhtml and svg documents by passing
appropriate name/namespaces to createDocument.

Comment 3

[Doron Rosenberg (IBM)]

Indeed, HTMLDOMImplementation's createHTMLDocument() is no longer in specs, my
bad.  Renaming the bug.

Note that in IE, createDocumentFragment returns a full HTMLDocument, so that is
how this got brought up at IBM.

Comment 4

[Fabian Guisset]

there's a patch for this in bug 33871

Comment 5

[Doron Rosenberg (IBM)]

So could we make document.implementation.createDocument create html documents by
giving it a mimetype?

Comment 6

[Boris Zbarsky [:bzbarsky]]

createDocument is specified at
http://www.w3.org/TR/2004/PR-DOM-Level-3-Core-20040205/core.html#ID-102161490

We could maybe hack together something where using an HTML4 doctype does the
right thing?

Comment 7

[Johnny Stenback (:jst)]

Yeah, I think that's a reasonable approach.

Comment 8

[Doron Rosenberg (IBM)]

Attachment: first try

Comment 9

[Doron Rosenberg (IBM)]

Comment on attachment 151944 [details] [diff] [review]
first try

Thanks for peterv for all the help.

Should I return somethign for unknown namespaces perhaps?

Comment 10

[Johnny Stenback (:jst)]

Comment on attachment 151944 [details] [diff] [review]
first try

Looks good. No need to return anything for unknown namespaces. People should be
able to create documents in whatever unknown namespace etc.

sr=jst

Comment 11

[Peter Van der Beken [:peterv]]

Comment on attachment 151944 [details] [diff] [review]
first try

>+  // check the namespace
>+  if (aNamespaceURI.Equals(NS_LITERAL_STRING("http://www.w3.org/1999/xhtml"))) {
>+    // xhtml
>+    rv = NS_NewHTMLDocument(getter_AddRefs(doc));
>+#ifdef MOZ_SVG
>+  } else if (aNamespaceURI.Equals(NS_LITERAL_STRING("http://www.w3.org/2000/svg"))) {

Move the else onto its own line.

>+    // svg
>+    rv = NS_NewSVGDocument(getter_AddRefs(doc));
>+#endif    
>+  } else {

Same here.

>   if (!doc)
>     return NS_ERROR_OUT_OF_MEMORY;
> 

>   if (NS_FAILED(rv)) {
>-    delete doc;
>-
>     return rv;
>   }

No need to check both doc and rv, just NS_ENSURE_SUCCESS(rv, rv);

>+    rv = domDoc->CreateElementNS(aNamespaceURI, aQualifiedName,
>                               getter_AddRefs(root));

Align getter_AddRefs with the opening parenthesis.

Comment 12

[Peter Van der Beken [:peterv]]

Do we want to add support for XUL documents?

Comment 13

[[e-mail]]

Comment on attachment 151944 [details] [diff] [review]
first try

>+  if (aNamespaceURI.Equals(NS_LITERAL_STRING("http://www.w3.org/1999/xhtml"))) {
if (aNamespaceURI.EqualsLiteral("http://www.w3.org/1999/xhtml")) {

Comment 14

[Axel Hecht]

I understood both comment #6 and the level 3 spec to talk about doctypes as the
deciding criteria, the patch seems to use namespaces though.
Is that intenional?

Comment 15

[Doron Rosenberg (IBM)]

If we are to use doctypes which ones would be used to create HTML documents? And
XUL doesn't seem to have a doctype.

Comment 16

[Doron Rosenberg (IBM)]

Regarding XUL - I took the hard way and implemented a NS_NewXULDocument that
takes a nsIDocument (the current one needs a nsIXULDocument).  Was a good lesson.

Should I use this for consistency sake or simply QI my nsIDocument to a
nsIXULDocument in my code?

Comment 17

[Doron Rosenberg (IBM)]

Attachment: Fix review comments and add XUL document creation

Comment 18

[Axel Hecht]

Comment on attachment 152945 [details] [diff] [review]
Fix review comments and add XUL document creation

>Index: content/xml/document/src/nsXMLDocument.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/content/xml/document/src/nsXMLDocument.cpp,v
>retrieving revision 1.214
>diff -u -r1.214 nsXMLDocument.cpp
>--- content/xml/document/src/nsXMLDocument.cpp	25 Jun 2004 12:25:59 -0000	1.214
>+++ content/xml/document/src/nsXMLDocument.cpp	12 Jul 2004 14:31:20 -0000
>@@ -91,6 +91,11 @@
> #include "nsIJSContextStack.h"
> #include "nsNodeInfoManager.h"
> #include "nsContentCreatorFunctions.h"
>+#include "nsIXULDocument.h"

is this going to break minimo? They don't build XUL, IIRC


<...>
>+  // check the namespace
>+  if (aNamespaceURI.EqualsLiteral("http://www.w3.org/1999/xhtml")) {
>+    // xhtml
>+    rv = NS_NewHTMLDocument(getter_AddRefs(doc));
>+  } else if (aNamespaceURI.EqualsLiteral("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul")) {
>+    // xul

---
>+    nsCOMPtr<nsIXULDocument> xulDoc = do_QueryInterface(doc);
>+    rv = NS_NewXULDocument(getter_AddRefs(xulDoc));
___

How can this work? It might be that do_QueryInterface checks for null, but I
see no
way that xulDoc will point to anything related to doc.
nsCOMPtr<nsIXULDocument> xulDoc;
rv = NS_NewXULDocument(getter_AddRefs(xulDoc));
NS_ENSURE_SUCCESS(rv, rv);
doc = do_QueryInterface(xuldoc);
sounds more like it.

>+#ifdef MOZ_SVG
>+  } else if (aNamespaceURI.EqualsLiteral("http://www.w3.org/2000/svg")) {
>+    // svg
>+    rv = NS_NewSVGDocument(getter_AddRefs(doc));
>+#endif    
>+  } else {
>+    // default to XMLDocument for backwards compat
>+    rv = NS_NewXMLDocument(getter_AddRefs(doc));
>+  }  

<...>

Comment 19

[Doron Rosenberg (IBM)]

Attachment: ifdef check XUL and do it the right way for XUL documents

Pike is right, debug build hung with that code.  Fixed that.