Last Comment Bug 230214 - doesn't implement the HTML-DOM for XHTML created as the result of an XSLT Transformation
: doesn't implement the HTML-DOM for XHTML created as the result of an XSLT Tra...
Status: NEW
:
Product: Core
Classification: Components
Component: XSLT (show other bugs)
: Trunk
: x86 Windows XP
: -- minor with 14 votes (vote)
: ---
Assigned To: Peter Van der Beken [:peterv]
:
Mentors:
http://home.arcor.de/martin.honnen/mo...
: 325835 346886 561083 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-01-06 09:16 PST by Davey Shafik
Modified: 2015-01-26 08:39 PST (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Main XML for test case (97 bytes, text/xml)
2006-12-27 08:04 PST, spyowl
no flags Details
XSLT for test case (1.18 KB, text/xml)
2006-12-27 08:06 PST, spyowl
no flags Details
Main XML for test case (142 bytes, text/xml)
2006-12-27 10:20 PST, spyowl
no flags Details
Workaround example (1.34 KB, text/xml)
2008-06-30 20:35 PDT, David Eckel
no flags Details

Description Davey Shafik 2004-01-06 09:16:42 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 MultiZilla/1.6.0.0e
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 MultiZilla/1.6.0.0e

When transforming using XSLT client-side to XHTML, the HTML-DOM is not
implemented for the result tree. This is not the case when XHTML is served directly.

This means, for example, you cannot access document.body in XHTML results of
XSLT Transformations, but you CAN access document.body when the document is
served as XHTML.

Reproducible: Always

Steps to Reproduce:
1. Transform an XML document to XHTML
2. Try to access the DOM

Actual Results:  
Error: document.body has no properties
Source File: http://pixelated-dreams.com/p-d.js
Line: 13

Expected Results:  
It should have created the DOM and the document.body node should have been there.

You can work around this problem in particular by putting an id on the body
element and using:

document.getElementById('bodys_id')
Comment 1 Jonas Sicking (:sicking) 2004-01-06 09:19:23 PST
we should instantiate a real xhtml-document when the root element is an
xhtml:html element. Same goes for svg-documents.
Comment 2 Ben 2005-02-17 09:46:49 PST
There appears to be no workaround for document.cookie , at least until
DOMImplementation.getFeature() is implemented.

This means a choice between client-side transformation, and client-side scripts
using cookies. Tbh, I'd rather have both.
Comment 3 Jonas Sicking (:sicking) 2006-05-23 14:53:03 PDT
*** Bug 325835 has been marked as a duplicate of this bug. ***
Comment 4 Jonas Sicking (:sicking) 2006-12-06 09:53:38 PST
*** Bug 346886 has been marked as a duplicate of this bug. ***
Comment 5 Ruvim Pinka 2006-12-06 11:44:42 PST
Is Bug 303557 have a same reason ?
Comment 6 spyowl 2006-12-26 12:38:33 PST
(In reply to comment #2)
> There appears to be no workaround for document.cookie , at least until
> DOMImplementation.getFeature() is implemented.

Just to clear this up, the getfeature method is implemented. However, there is no access to cookies using that interface.

This is the only bug that's preventing me from migrating the whole controlled environment (internal application) from XML/XSLT/HTML to XML/XSLT/XHTML. The workaround to most everything except cookies - i.e. not using HTML DOM, even though theoretically possible, is not practical especially when existing applications are written to the HTML DOM.

Finally, Mozilla already renders the XHTML generated this way as HTML - e.g. HTML forms, elements, etc. are all there. Why can't the logic that decides how to render the document and the logic that decides what DOM objects to instantiate as a result of it be consistent with each other? And if the way it currently works is wrong (i.e. it should not be rendering as HTML because it doesn't "recognize" the HTML document) then why can't the logic be based on xsl:output method (xml), media-type (application/xhtml+xml) and the existence of the root xhtml:html element?

It seems like a relatively easy solution to a bug that's been open for almost 3 years.
Comment 7 Ruvim Pinka 2006-12-27 02:28:05 PST
Also, there can be used doctype-system attribute of xsl:output element to generate DOCTYPE (for example, see attachment https://bugzilla.mozilla.org/attachment.cgi?id=233758 of Bug 346886).

BTW, I would have been expecting a recursive transformation when the output XML have a stylesheet reference :)
Comment 8 Peter Van der Beken [:peterv] 2006-12-27 04:09:32 PST
(In reply to comment #7)
> BTW, I would have been expecting a recursive transformation when the output XML
> have a stylesheet reference :)

No, see http://www.w3.org/TR/xslt#data-model ("Processing instructions and comments in the stylesheet are ignored").
Comment 9 Peter Van der Beken [:peterv] 2006-12-27 04:20:22 PST
pixelated-dreams.com doesn't use anything XSLT related afaics.
Comment 10 Ruvim Pinka 2006-12-27 04:42:59 PST
Example of recursive transformation.

Source xml document, fragment:
<?xml version="1.0" encoding="ascii" ?>
<?xml-stylesheet type="text/xsl" href="struct-pre.xsl"?>
<root>...


The struct-pre.xsl document, fragment:

<xsl:output omit-xml-declaration="no" />
<xsl:template match="/" >
  <xsl:processing-instruction name="xml-stylesheet">
    <xsl:text>type="text/xsl" href="struct-second.xsl"</xsl:text>
  </xsl:processing-instruction>
  <xsl:apply-templates />
</xsl:template>

Тow, the output xml document will get xml-stylesheet instruction and may have next transformation with struct-second.xsl.
Comment 11 Peter Van der Beken [:peterv] 2006-12-27 04:45:31 PST
Ah, yes. I don't think we'll support that, if you want to pipeline do it on the server.
Comment 12 Ruvim Pinka 2006-12-27 07:27:27 PST
(In reply to comment #11)
> Ah, yes. I don't think we'll support that, if you want to pipeline do it on the
> server.

We can do it on the client by using JavaScript. But sometimes such pipelining without JavaScript is more elegant and traffic less.
Comment 13 spyowl 2006-12-27 08:04:09 PST
Created attachment 249764 [details]
Main XML for test case
Comment 14 spyowl 2006-12-27 08:06:10 PST
Created attachment 249765 [details]
XSLT for test case
Comment 15 spyowl 2006-12-27 08:16:32 PST
(In reply to comment #9)
> pixelated-dreams.com doesn't use anything XSLT related afaics.
> 

So that we don't have to rely on original reporter's URLs remaining the same throughout, I uploaded the XML and XSLT files that can be used to reproduce the behavior described.
Comment 16 spyowl 2006-12-27 10:20:44 PST
Created attachment 249777 [details]
Main XML for test case

Modified stylesheet URI in the XML so that it points to the uploaded XSL on bugzilla.
Comment 17 Jonas Sicking (:sicking) 2006-12-27 10:25:03 PST
Pipelineing has nothing to do with this bug. Feel free to file a separate bug on it.
Comment 18 David Eckel 2008-06-30 20:35:40 PDT
Created attachment 327530 [details]
Workaround example

One way to work around the issue is to grab an HTML DOM from a nested HTML object and add the setter and getter for document.cookie.
Comment 19 David Eckel 2008-06-30 20:40:48 PDT
I should clarify that the attached workaround is only for document.cookie, not for all of the missing HTML DOM properties and methods.
Comment 20 Nickolay_Ponomarev 2010-04-25 07:27:28 PDT
*** Bug 561083 has been marked as a duplicate of this bug. ***
Comment 21 The 8472 2011-01-04 07:29:58 PST
I also ran into this issue trying to serve xhtml as xml documents. To render them in IE it requires a dummy XSLT transformation, which in turn breaks firefox as it does not add HTML DOM to the transformed output, making this approach useless as it breaks pretty much all javascript.
Comment 22 Milind R 2015-01-22 12:29:33 PST
I can't believe this bug is still not fixed. It should be simple. Cmon Mozilla. Chrome has done it. IE is in even worse shape, as expected.

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