Bug Tracker

Opened 14 years ago

Closed 12 years ago

Last modified 11 years ago

#4895 closed bug (duplicate)

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:


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">



<script type="text/javascript" src="/static/jquery-1.3.2.js"/> <script type="text/javascript">

$(document).ready(function() {




</head> <body>

This should be hidden: <span id="foo">Foo</span>





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.

Change History (14)

comment:1 Changed 14 years ago by inozemtsev

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.

comment:2 Changed 14 years ago by inozemtsev

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.

comment:3 Changed 14 years ago by russellneufeld

Using <xsl:output method="html" /> does indeed seem to work around the issue. Thanks for the update and the work around!

comment:4 Changed 13 years ago by Arrviasto

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).

comment:5 Changed 13 years ago by atesgoral

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...

comment:6 Changed 13 years ago by dmethvin

Component: unfiledsupport

comment:7 Changed 12 years ago by addyosmani

#4264 is a duplicate of this ticket.

comment:8 Changed 12 years ago by dvdckl

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.

comment:9 Changed 12 years ago by Rick Waldron

Priority: majorlow
Resolution: duplicate
Status: newclosed

comment:10 Changed 12 years ago by Rick Waldron

Duplicate of #4264.

comment:11 Changed 12 years ago by dvdckl

Can someone reopen one of these two bugs? They're currently pointing to each other as duplicates: #4264, #4895.

comment:12 Changed 12 years ago by jitter

Milestone: 1.4
Resolution: duplicate
Status: closedreopened

comment:13 Changed 12 years ago by jitter

Resolution: duplicate
Status: reopenedclosed

comment:14 Changed 12 years ago by jitter

Duplicate of #6598.

Note: See TracTickets for help on using tickets.