#4400 closed bug (invalid)
jQuery incorrectly identifies XSLT-generated HTML document as XML
Reported by: | IvanPepelnjak | Owned by: | IvanPepelnjak |
---|---|---|---|
Priority: | major | Milestone: | 1.4 |
Component: | selector | Version: | 1.3.2 |
Keywords: | Firefox XSLT | Cc: | |
Blocked by: | Blocking: |
Description
Client-side XSLT-to-HTML transformation in Firefox in combination with custom namespaces might generate a mixture of uppercase and lowercase tag names (clearly a Firefox bug).
The data structures generated by Firefox after this transformation indicate to jQuery that it's working on a an XML document, but due to the mixed-case tags (in combination with isXML being true), the Sizzle filters don't work correctly.
Furthermore, the "getElementsByClassName" function is available in XSLT-transformed HTML document, so the Sizzle engine could use the efficient version of class matching algorithm. However, the Sizzle function using getElementsByClassName returns immediately (again due to isXML flag = true).
To work around the Firefox bug, the isXML and isXMLDoc functions should identify the XSLT-transformed document with HTML root node as HTML, not XML. But because FireFox retains lowercase tag names in the XSLT transformation results (regardless of whether the xsl:output is set to HTML or XML), the root element node name is not "HTML" but "html" and the isXML functions return "true".
To fix this bug, we simply have to use the toUpperCase() function when testing the root element name:
var isXML = function(elem){
return elem.nodeType === 9 && elem.documentElement.nodeName.toUpperCase() !== "HTML" !!elem.ownerDocument && isXML( elem.ownerDocument );
};
Attachments (2)
Change History (6)
Changed 14 years ago by
Changed 14 years ago by
XSL transformation. The resulting Web page has two links. Clicking on either one will print the link's nodeName (once "a", once "A").
comment:1 Changed 14 years ago by
I've been working a similar bug to this one, and I think this bug is related to #4218: http://dev.jquery.com/ticket/4218
It seems like if this case-comparison issue gets resolved, about a dozen standing bugs in 1.3.2 will fall.
I'm not sure what the thinking is for when to use jquery.nodeName(x,y) and when to use the standard DomElement.nodeName() methods. It seems to me that the jquery extended version which corrects for case should be used in all instances.
comment:2 Changed 13 years ago by
Component: | unfiled → selector |
---|
comment:3 Changed 12 years ago by
Owner: | set to IvanPepelnjak |
---|---|
Status: | new → pending |
Could you please confirm this is still an issue in current versions of jQuery? Thanks!
comment:4 Changed 12 years ago by
Resolution: | → invalid |
---|---|
Status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
Source XML document