Last Comment Bug 450160 - DOMImplementation createDocument does not create an HTML document
: DOMImplementation createDocument does not create an HTML document
Status: RESOLVED FIXED
[verified1.9.1b4: Bv1]
: fixed1.9.1
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal with 2 votes (vote)
: ---
Assigned To: Olli Pettay [:smaug] (way behind * queues, especially ni? queue)
:
:
Mentors:
http://www.w3.org/TR/2004/REC-DOM-Lev...
Depends on:
Blocks: acid3
  Show dependency treegraph
 
Reported: 2008-08-11 14:36 PDT by Robert O'Callahan (:roc) (email my personal email if necessary)
Modified: 2014-10-29 07:03 PDT (History)
19 users (show)
bugzillamozillaorg_serge_20140323: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
an interpretation of dom 3 .createDocument (12.68 KB, patch)
2008-09-18 07:55 PDT, Olli Pettay [:smaug] (way behind * queues, especially ni? queue)
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Splinter Review
(Bv1) Remove blank lines in log [Checkin: Comment 11 & 12] (4.56 KB, patch)
2009-04-04 12:51 PDT, Serge Gautherie (:sgautherie)
bugs: review+
Details | Diff | Splinter Review

Description Robert O'Callahan (:roc) (email my personal email if necessary) 2008-08-11 14:36:42 PDT
The Acid3 test does something like this:

var doctype = document.implementation.createDocumentType("html", "-//W3C//DTD XHTML 1.0 Strict//EN", "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd");
var doc = document.implementation.createDocument("http://www.w3.org/1999/xhtml", "html", doctype);
doc.documentElement.appendChild(doc.createElementNS("http://www.w3.org/1999/xhtml", "head"));
doc.documentElement.appendChild(doc.createElementNS("http://www.w3.org/1999/xhtml", "body"));
doc.body.appendChild(doc.createElementNS("http://www.w3.org/1999/xhtml", "form"));

but doc.body is not defined because we create an nsXMLDocument.

I guess all that's needed is to change the createDocument logic to behave more like the XML sink?
Comment 1 Robert O'Callahan (:roc) (email my personal email if necessary) 2008-08-11 17:52:41 PDT
Setting up an nsHTMLDocument actually looks pretty hard :-(. Someone with more mojo than me should look at it.

The other option is to just move functionality up to nsDocument. HTML5 says that every document object should implement all document interfaces so this is really what we should be doing anyway. A lot of it would move up relatively easily but of course the stuff that's complicated to set up in nsHTMLDocument would be hard to move.
Comment 2 Jonas Sicking (:sicking) No longer reading bugmail consistently 2008-08-11 18:06:31 PDT
I'm haven't yet looked into the feasibility of what HTML5 says.

That said, it shouldn't be *that* hard to create a HTML document. XSLT does a decently good job, look at

http://mxr.mozilla.org/mozilla-central/source/content/xslt/src/xslt/txMozillaXMLOutput.cpp#844
http://mxr.mozilla.org/mozilla-central/source/content/xml/document/src/nsXMLContentSink.cpp#387
Comment 3 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2008-09-18 07:55:05 PDT
Created attachment 339252 [details] [diff] [review]
an interpretation of dom 3 .createDocument

This is my interpretation of the DOM 3 Core; create document based on doc 
type's publicId. The systemId may in principle point to any place, it doesn't 
even have to be an absolute URI.

WebKit does something wrong here, it creates the document based on
the namespaceURI parameter of .createDocument().
That is not what the spec says:
  'Note that based on the DocumentType given to create the document, the 
   implementation may instantiate specialized Document objects that support 
   additional features than the "Core"'

A fun part is also that ACID3 relies on an "implementation _may_" feature :/
Anyway, the patch fixes ACID3 test 98.

Jonas, Boris, anyone, comments?
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2008-09-18 18:13:26 PDT
> A fun part is also that ACID3 relies on an "implementation _may_" feature :/

That would make it a bug in the test.  Have you reported it to Ian?

Patch looks OK on quick skim; I'll try to do a detailed review on Monday, probably.  One question:  do we currently create docshell-less HTML documents anywhere?  If not, what sort of auditing have you done to make sure that we don't have code that assumes an HTML document is always in a docshell, has a window, etc?
Comment 5 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2008-09-19 02:00:29 PDT
(In reply to comment #4)
> One question:  do we currently create docshell-less HTML documents
> anywhere?  If not, what sort of auditing have you done to make sure that we
> don't have code that assumes an HTML document is always in a docshell, has a
> window, etc?
We do support .cloneNode nowadays. And I re-checked some code and as far as I see
having docshell-less htmldocument means that contentEditable/midas isn't available
and document.open/write/close don't work (like they don't work with xhtml anyway).
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2008-09-19 07:09:52 PDT
> We do support .cloneNode nowadays.

You mean on documents?

Basically, did you look at the various window, script global object, container, scope object, etc users in nsHTMLDocument and in places that explicitly work on HTML documents?
Comment 7 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2008-09-19 10:18:51 PDT
I searched HTMLDocument in the tree and so far nothing bad found.
.open/.write/.close and different editing things just won't work - could
file a followups to fix those if really needed.
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2008-09-19 10:25:51 PDT
Having those not work on in-memory HTML seems just fine to me.
Comment 9 Jonas Sicking (:sicking) No longer reading bugmail consistently 2008-09-21 03:08:31 PDT
XSLT has also created out-of-docshell HTML documents for a long time (through xsltprocessor.transformToDocument). Not sure that we auditid very many things though.

There is also the question of what .cookies should do when gotten/set.
Comment 10 Serge Gautherie (:sgautherie) 2009-04-04 12:51:42 PDT
Created attachment 371074 [details] [diff] [review]
(Bv1) Remove blank lines in log
[Checkin: Comment 11 & 12]

Aren't they useless ?
Comment 11 Serge Gautherie (:sgautherie) 2009-04-04 14:12:12 PDT
Comment on attachment 371074 [details] [diff] [review]
(Bv1) Remove blank lines in log
[Checkin: Comment 11 & 12]


http://hg.mozilla.org/mozilla-central/rev/ef8da5d2aeb7
Comment 12 Serge Gautherie (:sgautherie) 2009-04-05 05:45:39 PDT
Comment on attachment 371074 [details] [diff] [review]
(Bv1) Remove blank lines in log
[Checkin: Comment 11 & 12]


http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c8b3efbf0f48
Comment 13 Serge Gautherie (:sgautherie) 2009-04-05 14:06:52 PDT
(In reply to comment #12)
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c8b3efbf0f48

This part is verified1.9.1, per
{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1238938947.1238945640.4337.gz&fulltext=1
Linux comm-central unit test on 2009/04/05 06:42:27
}

Note You need to log in before you can comment on or make changes to this bug.