Bug Tracker

Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#13754 closed bug (fixed)

jQuery doesn't work in a non-HTML document in UAs that have innerHTML on Element and create non-HTML elements via createElement

Reported by: [email protected] Owned by: [email protected]
Priority: low Milestone: 1.10
Component: support Version: 1.9.1
Keywords: Cc:
Blocked by: Blocking:


See https://bugzilla.mozilla.org/show_bug.cgi?id=858850#c8 but the short of it is that in an environment in which the following are true:

1) innerHTML exists on all elements 2) createElement creates non-HTML elements

(for example, an XML document in Firefox 20 or later), jQuery's initialization throws an exception because it tries to set a.style.cssText on an "a" that's not an HTMLElement and hence has no .style.

Change History (9)

comment:1 Changed 10 years ago by anonymous

For example, this makes jQuery not work in SVG documents in current Gecko....

comment:2 Changed 10 years ago by [email protected]

I'm the filer of the FF bug. It arises with the update from FF 19 to 20. So I really wonder why nobody else complains broken scripts when doing client side XSLT to XML transforms?

I'm living a long time with the limited capabilities of jquery used in XML documents. Until now it worked good enough to search DOM nodes and manipulate properties like CSS in a cross browser way. But modules like jquery UI never worked because using the append method with strings of HTML code relying on a working innerHtml on DOM nodes. That's a no go on XML DOMs.

So I will request a fundamental change in XML documents: jquery should use createDocumentNS and parse XHTML/XML strings (to append) on its own (simple stack machine to match open/closing tags and attributes, createTextNode for the rest). You should introduce a RegisterNamespace method to associate prefixes to NS-URIs and split node names on the first ':' to automatically detect the namespace to use in createElementNS. In case of a missing prefix you can fall back to createElement.

That behaviour would be a reasonable design suitable for all browsers and strict standard conforming even in HTML4/5.

comment:3 Changed 10 years ago by dmethvin

Owner: set to [email protected]
Status: newpending

To the original report, can you provide a test case? This sounds like it's outside the scope of jQuery's role as an HTML DOM library.

What postbox is asking for is a huge amount of code (a Javascript-based XML parser, really?) and doesn't belong in the core library. It should be a plugin to effectively serve that tiny portion of people who need it.

comment:4 Changed 10 years ago by dmethvin

Status: pendingopen

Oh, now I see what you're saying. All we're going to do to "fix" that is skip the support.js code for that case. Will that move the ball down the field at all?

comment:5 Changed 10 years ago by dmethvin

Component: unfiledsupport
Milestone: None1.10
Priority: undecidedlow

comment:6 Changed 10 years ago by gibson042

Resolution: fixed
Status: openclosed

comment:7 Changed 10 years ago by anonymous

Yes, just continuing to skip support for cases like his is fine by me. The change in c6a694e1c262acb941b7fd86663f186656496bbc looks good, thanks!

comment:8 Changed 10 years ago by dmethvin

I really wonder why nobody else complains broken scripts when doing client side XSLT to XML transforms?

Because it's incredibly rare. jQuery *really* wants an HTML DOM so it can work right. We support basic selection/traversal/manipulation on XML documents, but for example attaching data and events to XML elements is not possible across all the browsers we support. XML issues have been on our wontfix list for ages.

Looks like #13193 may be related.

comment:9 Changed 9 years ago by Richard Gibson

Support: Skip style-based tests when element.style is undefined

Fixes #14785 Ref #13754 Ref badcd1b6f301e6253405f17759c1270549a34e12

Changeset: a7ea12a9a7c696a14455bfe4bfebf984dd329832

Note: See TracTickets for help on using tickets.