325835 - XSLT transformation result with xsl:output media-type="application/xhtml+xml" does not implemented HTML DOM (e.g. document.body, document.forms)

Status: RESOLVED DUPLICATE of bug 230214

(Core :: XSLT, defect)

Description

[Lucky]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Each time you load an xml that has an associated xsl transform document, the resultant document does not mirror what the expected results should be.  Primarily the DOM does not contain similar properties to what you would get by saving out the resultant source code to another filetype.

Reproducible: Always

Steps to Reproduce:
1. create xsl file that renders XHTML compliant code
2. create xml file that uses the XHTML xsl file
3. load the xml file into firefox
4. try to access document.body

Actual Results:  
document.body = null;
or
document.body = undefined;
dependant on which method/media-type you apply to the xsl:output element.

Expected Results:  
an XHTML DOM similar to the one, as if you saved the results to .xhtml file, and loaded them into the browser.

After short discussion in newsgroups, others have confirmed that the current results are not as expected, and could be patched.  I'm not entirely concerned with having the document.body, but really wanted to help document what all the differences that may come about doing this type of transform processing "on-the-fly."

Comment 1

[Martin Honnen]

If you serve an XHTML document to Mozilla with Content-Type application/xhtml+xml then Mozilla builds an HTML DOM with properties like document.body, document.forms, document.images defined in the W3C DOM Level 2 HTML specification for HTML 4.01 and XHTML 1.0 documents.
However when Mozilla with its XSLT processor creates an XHTML result document with xsl:output media-type="application/xhtml+xml" then the document has the proper content type according to the document.contentType property but the properties like document.body, document.forms defined by the HTML DOM are missing.
The test case at
<http://home.arcor.de/martin.honnen/mozillaBugs/xslt/HTMLDOMCheckAfterXSLT1.xml>
shows that, it is an XHTML document served as text/xml with a processing instruction to a stylesheet doing an identity transformation and having the xsl:output element

<xsl:output
  media-type="application/xhtml+xml"
  omit-xml-declaration="no"
  encoding="UTF-8"
  doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"
  doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
  cdata-section-elements="xhtml1:script" />

Firefox 1.5.0.1 then shows the script output:

document.contentType: application/xhtml+xml

document.body: undefined

document.forms: undefined

document.images: undefined

If the same XHTML document is served as application/xhtml+xml without transformation as done here:
<http://home.arcor.de/martin.honnen/mozillaBugs/xslt/HTMLDOMCheck1.xhtml>
then the script output with Firefox 1.5.0.1 is

document.contentType: application/xhtml+xml

document.body: [object HTMLBodyElement]

document.forms: [object HTMLCollection]

document.images: [object HTMLCollection]

When testing with the latest Firefox trunk nightly (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060203 Firefox/1.6a1) the results are as with Firefox 1.5.0.1 so I confirm this bug.

Also changing summary to more accurate describe the problem.

Comment 2

[Martin Honnen]

As someone elsewhere pointed out my original test cases with a pure identity transformation copies everuthing including the <?xml-stylesheet?> processing instructions which could lead to infinite recursion if a browser applies the first transformation and then finds the processing instruction again in the transformation result document and tries to transform again.

I have therefore made a new set of test cases where an identity transformation is used that does not copy <?xml-stylesheet?> processing instructions.
Changing URL field in bugzilla form therefore.
Test case is now at:
<http://home.arcor.de/martin.honnen/mozillaBugs/xslt/HTMLDOMCheckAfterXSLT3.xml>
using XSLT stylesheet at:
<http://home.arcor.de/martin.honnen/mozillaBugs/xslt/identityApplicationXHTMLXMLOutput2.xml>

Nothing changes in regard to Mozilla's behavior the bug is about, the result document has the content type application/xhtml+xml but the W3C HTML DOM Level 2 specific properties like document.body, document.forms are not there.

Comment 3

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

so the question now is what should we use to determine what type of document to create?

The spec mandates that we look at the name of the root element to choose between creating an XML document and a HTML document.

We can either do the same for XHTML and look at the root element to see if the name is "html" and namespace is the xhtml namespace then we create an xhtml document. Or we could just look at the mime-type attribute in the <output> element.

I don't want to use the doctype attributes simply because those values are hard to remember and easy to get wrong. Additionally there are several xhtml doctypes, and the list might change, so it'd be a neverending hunt.

Alternativly, we could add new values to the <output method=".."> attribute. However i'm not very exited about that since those should be namespaced and thus reqire an additional xmlns attribute set.


What I think I lean towards is using the mime type if one is defined, and otherwise looking at the name+namespace of the root element.

Comment 4

[Axel Hecht]

Do we know what content does? I guess we shouldn't try to make up "our mind", but
just follow the scheme that content uses.
Now that we're in content, we may even be able to reuse the code.

Comment 5

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

Content *only* looks at the mime type. But it does that to differ between HTML and XML too, which we can't do since the spec says otherwise.

The reason i'm reluctant to only use the mime-type is that xslt authors are used to not have to use the <xsl:output> element. Also we'll get in a situation where XHTML "work" in IE (since it treats everything in html), but not in gecko since we'll get the wrong document.

We unfortunatly can't reuse the content code. It creates a content viewer and probably a bunch of other crap besides the document [1]. We could maybe reuse the lists of mime types though.

[1] http://lxr.mozilla.org/mozilla/source/layout/build/nsContentDLF.cpp#159

Comment 6

[Lucky]

Straight from W3 Specs

The default for the method attribute is chosen as follows. If

    * the root node of the result tree has an element child,
    * the expanded-name of the first element child of the root node (i.e. the document element) of the result tree has local part html (in any combination of upper and lower case) and a null namespace URI, and
    * any text nodes preceding the first element child of the root node of the result tree contain only whitespace characters,

then the default output method is html; otherwise, the default output method is xml.
The default output method should be used if there are no xsl:output elements or if none of the xsl:output elements specifies a value for the method attribute.

So no <xsl:output> or no @method="" declared
 - <html> with no namespace = html
 - <html xmlns="xhtmlNS"> = html/xhtml
 - <other root> = xml

Any <xsl:output @method="html"> should attempt to render that type?

Surely not so easy to implement exactly, but just trying to help.

Comment 7

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

I don't see what you're basing

 - <html xmlns="xhtmlNS"> = html/xhtml

on. There is nothing in the spec that says anything to that effect.

Comment 8

[Lucky]

I was simply refering to however an xhtml html document would default to when opened up in firefox?

If I saved out the results of such transformation, and set the file extension to html.

    * "HTML compatible" XHTML (as defined in appendix C of the XHTML 1.0 specification) may be served as text/html, but it should be served as application/xhtml+xml.

Comment 9

[Helder Rossa]

Adding this to the XSL:
<xsl:output 
    method="html" 
    encoding="UTF-8" 
    omit-xml-declaration="no"
    doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN" />

And, in the XSL template, if I do this in the output:
<html xmlns="http://www.w3.org/1999/xhtml">
then the document.body = undefined



if I do this in the output:
<html>
then the document.body = [object HTMLBodyElement]


this occurs in Firefox 1.5.0.1

Comment 10

[Jan Pingel]

bug 230214 seems to be a duplicate of this.


I've noticed forms generated by XSLT don't seem to remember login/password with the password manager, would this be because of document.forms being undefined?

Comment 11

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

That's the unrelated bug 213026

Comment 12

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

*** This bug has been marked as a duplicate of 230214 ***