Bug Tracker

Ticket #5206 (closed enhancement: wontfix)

Opened 5 years ago

Last modified 3 years ago

create namespaced elements when building the jQuery.support object

Reported by: bridget.almas Owned by:
Priority: low Milestone: 1.7
Component: support Version: 1.5
Keywords: needsreview,1.7-discuss Cc:
Blocking: Blocked by:

Description (last modified by john) (diff)

To build the jQuery.support object, the code creates a number of html elements using document.createElement and then proceeds to test the browser behavior against them. This is problematic when jQuery is used in an XUL extension, as the elements are not recognized as HTML elements when the document object used to create them is an XUL document. I think using document.createElementNS, specifying the xhtml namespace, rather than document.createElement might work around this issue.

Change History

comment:1 Changed 4 years ago by dmethvin

  • Component changed from unfiled to support

comment:2 Changed 4 years ago by rwaldron

  • Priority changed from major to low
  • Milestone changed from 1.4 to 1.5

comment:3 Changed 4 years ago by snover

  • Keywords needsreview added
  • Milestone 1.5 deleted

Not sure if we are supporting an XUL context.

comment:4 Changed 4 years ago by dmethvin

  • Keywords needsreview removed
  • Status changed from new to open
  • Version changed from 1.3.2 to 1.4.3
  • Milestone set to 1.5

comment:5 Changed 4 years ago by addyosmani

  • Keywords needsreview added

comment:6 Changed 4 years ago by snover

#5776 is a duplicate of this ticket.

comment:7 follow-up: ↓ 8 Changed 4 years ago by ilya.kharlamov@…

There is a special fork of jQuery called  jQuery-xul at github, it is compatible with FireFox xul model.

comment:8 in reply to: ↑ 7 Changed 4 years ago by ekesken

Replying to ilya.kharlamov@…:

There is a special fork of jQuery called  jQuery-xul at github, it is compatible with FireFox xul model.

i tried your jquery-xul, unfortunately it didn't work for me. i've a simple toolbar application, i don't have any problem with my main application overlay, even with plane jquery-1.4.4 but in preferences dialog xul, jquery prevents xul elements' addition to dom.

there is no problem with jquery-1.2.6.

comment:9 Changed 4 years ago by jitter

  • Version changed from 1.4.3 to 1.5
  • Milestone set to 1.next

comment:10 Changed 4 years ago by jitter

#8172 is a duplicate of this ticket.

comment:11 Changed 3 years ago by john

  • Keywords needsreview,1.7-discuss added; needsreview removed

Nominating ticket for 1.7 discussion.

comment:12 Changed 3 years ago by rwaldron

  • Description modified (diff)

+0,

comment:13 Changed 3 years ago by jaubourg

-1, Well, script tag injection will also fail for one and other places too I'm sure. AFAIK, XUL extensions are not a supported environment and that has everything to do with XML being so unfriendlily pedantic.

comment:14 Changed 3 years ago by ajpiano

  • Description modified (diff)

+0, I think we'd need to a do a bit more research to find out more about that "might"

comment:15 Changed 3 years ago by timmywil

  • Description modified (diff)

+0,

comment:16 Changed 3 years ago by danheberden

+0, Need to see proof/working examples before committing to include this in 1.7

comment:17 Changed 3 years ago by paul.irish

  • Description modified (diff)

-1

comment:18 Changed 3 years ago by dmethvin

-1, No to blind createElementNS since it isn't supported by IE<9; is there some other way to support XUL?

comment:19 Changed 3 years ago by reesd

+1 on looking at improving this, it works pretty well as it is but then occasionally fails - usually because of the jQuery.support issue.

I agree it shouldn't be blind, perhaps it can detect that the innerHTML fails (completely I might add) and then look to see if its in Gecko/Firefox? Then try createElementNS? So its isolated to only Gecko cases?

I'll add there is a a hidden issue here, the user can create XUL and HTML elements. If we run the support tests against a XUL div the we are assuming the developer is creating XUL elements. That isn't always true, so its worth documenting somewhere that fact so folks are not surprised.

comment:20 Changed 3 years ago by rwaldron

I think there maybe some confusion here, the +1/-1/+0 is for the bugs, core and ui teams to vote on pending 1.7 issues. We apreciate your feedback and it will definitely be taken into consideration, but the voting is whitelisted.

comment:21 Changed 3 years ago by john

  • Description modified (diff)

-1, We definitely need to see more proof that this could work.

comment:22 Changed 3 years ago by scott.gonzalez

+0, I don't know enough about XUL to know if we want to support it

comment:23 Changed 3 years ago by jzaefferer

-1

comment:24 Changed 3 years ago by cowboy

+0

comment:25 Changed 3 years ago by rwaldron

  • Status changed from open to closed
  • Resolution set to wontfix
  • Milestone changed from 1.next to 1.7

Closing per 1.7 roadmap meeting resolution

Note: See TracTickets for help on using tickets.