Side navigation
#4895 closed bug (duplicate)
Opened July 13, 2009 03:18PM UTC
Closed November 21, 2010 02:18AM UTC
Last modified March 13, 2012 05:53PM UTC
div.style is undefined when loading jQuery as a result of XSLT
| Reported by: | russellneufeld | Owned by: | |
|---|---|---|---|
| Priority: | low | Milestone: | |
| Component: | support | Version: | 1.3.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
I'm seeing an exception in jQuery initialization when running an XSL transformation of an XML doc which produces HTML with jQuery code. jQuery gets through some of its initialization, however some basic methods like show() or hide() are undefined. Here's an example and suggested fix. Start with this XML doc:
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="/jquery.bug.xsl"?>
<directory/>
and this XSL doc named jquery.bug.xsl:
<?xml version="1.0" encoding="ISO-8859-1"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0" xmlns="http://www.w3.org/1999/xhtml">
<xsl:template match="directory">
<html>
<head>
<script type="text/javascript" src="/static/jquery-1.3.2.js"/>
<script type="text/javascript">
$(document).ready(function() {
$('#foo').hide();
});
</script>
</head>
<body>
This should be hidden: <span id="foo">Foo</span>
</body>
</html>
</xsl:template>
</xsl:stylesheet>
Put the XML and XSL doc on a webserver and load the XML doc through Firefox 3.0.11. (You seem to need to load the XML and XSL through a webserver and not from the filesystem, as Firefox doesn't do the XSLT when those files are loaded from the filesystem.)
What you should see in the browser is this:
This should be hidden:
However what you will see is
This should be hidden: Foo
This is because the hide() method is undefined, again due to an exception in jQuery initialization. The problem is on line 3121 of jQuery.1.3.2.js. This line:
div.style.display = "none";
Adding this
if (div.style) {
...
}
around that line and the line below it seems to fix the problem. Not sure exactly what those lines do, so I don't know if that's the right fix, but hopefully this helps.
Attachments (0)
Change History (14)
Changed July 25, 2009 09:08AM UTC by comment:1
Changed July 26, 2009 12:54AM UTC by comment:2
Looks like this is a bug in Firefox, not jQuery, and a pretty well-known one at that. The hack presented above only restores minimal functionality, but many more things are broken.
Firefox 3 DOM implementation really doesn't like client-side XSLT. To work around this bug, use
<xsl:output method="html" />
in the XSL stylesheet.
Changed July 27, 2009 01:55PM UTC by comment:3
Using <xsl:output method="html" /> does indeed seem to work around the issue. Thanks for the update and the work around!
Changed September 04, 2009 01:44PM UTC by comment:4
When I send XHTML as text/xml (PHP: header("Content-type: text/xml");), there is same effect. It is problem with xml and probably xhtml namespace (in xmlns attribute).
Changed April 01, 2010 09:18PM UTC by comment:5
I've been dealing with this problem since yesterday. I could be totally wrong, but the impression I got is that this is not a Firefox bug, but Firefox just being picky about namespaces.
When you declare a namespace with xmlns="http://www.w3.org/1999/xhtml", then you're obliged to use the *NS flavor of DOM methods (e.g. createElementNS) instead of the non-NS ones. I don't know if this according to the spec, or simply a Firefox bug like everyone else around seems to be claiming.
To help with the work I was doing in using jQuery with XHTML generated through XSL, I implemented a basic hack to hijack the non-NS DOM methods to make them internally use the NS flavors. The code is at: http://gist.github.com/352210
So if this is not a Firefox bug, maybe jQuery needs to be cognizant of namespace declarations in an XHTML document.
Again, I may be entirely wrong. Just wanted to bring a different angle to the table...
Changed June 13, 2010 01:26PM UTC by comment:6
| component: | unfiled → support |
|---|
Changed November 05, 2010 03:27PM UTC by comment:8
There's other details on why this issue occurs and how to fix documented in ticket #4264. Usually newer reports should be marked as duplicates of older ones.
Changed November 07, 2010 03:25PM UTC by comment:9
| priority: | major → low |
|---|---|
| resolution: | → duplicate |
| status: | new → closed |
Changed November 07, 2010 03:25PM UTC by comment:10
Duplicate of #4264.
Changed November 07, 2010 07:30PM UTC by comment:11
Changed November 21, 2010 02:18AM UTC by comment:12
| milestone: | 1.4 |
|---|---|
| resolution: | duplicate |
| status: | closed → reopened |
Changed November 21, 2010 02:18AM UTC by comment:13
| resolution: | → duplicate |
|---|---|
| status: | reopened → closed |
Changed November 21, 2010 02:19AM UTC by comment:14
Duplicate of #6598.
Confirming the bug in Firefox 3.5.1. IE works fine. Also, it seems that only the first line (div.style.display = "none") needs the if statement. Setting the innerHTML works fine on Firefox and IE.
It looks like this code is just testing browser support, and the display:none is being set to avoid having a div containing garbage appearing in the document. The div is never attached to a parent though, so display:none not being set as result of the if() test failing doesn't seem to be a problem.