#4908 closed feature (fixed)

Opened October 13, 2009 12:28PM UTC

Closed January 25, 2013 01:57PM UTC

Support cross-window use of plugins

Reported by: DaveOnCode Owned by:
Priority: major Milestone: 1.10.0
Component: [meta] ui.dev Version: 1.7.2
Keywords: Cc:
Blocked by: Blocking:
Description

One great jQuery's feature is that you can pass a context for a selector (ie: $("#target", top.document)) and this allows to use functions among different windows/iframes, anyway when jQuery UI attaches its own handlers, the context argument is ignored!

You can reproduce the problem creating an iframe inside a page and by placing into the iframe a code like:

$("#tabs", top.document).tabs();

You will see the tabs rendered in the page but, once you click on any tab you will get: "uncaught exception: jQuery UI Tabs: Mismatching fragment identifier."

These kind of errors are raised by all plugins.

Attachments (0)
Change History (10)

Changed October 13, 2009 11:49PM UTC by scottgonzalez comment:1

component: ui.core → [meta] ui.dev
milestone: TBD → 1.next
priority: blocker → major
type: bug → feature

Changed November 13, 2009 06:23PM UTC by scottgonzalez comment:2

summary: jQuery UI doesn't take into account the context of selector when it binds events handlers → Support cross-window use of plugins

Changed November 18, 2009 09:46AM UTC by maximbai comment:3

Can't apply 'sortable' plugin to elements in frame form the top frame.

Example:

1.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title></title>
<script src="jquery.js" type="text/javascript"></script>
<script src="jquery-ui.js" type="text/javascript"></script>
</head>
<body>
	<button onclick="makeSortable()">make sortable</button>
	<hr/>
	<iframe src="2.html" height="300" id="frm"></iframe>
	<script type="text/javascript">
	//<![CDATA[
	function makeSortable()
	{
		$0('#holder', $0('#frm').get(0).contentDocument).sortable({'axis': 'y'});
	}
	//]]>
</script>
</body>
</html>

2.html

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head><title></title></head>
<body>
	<div id="holder">
		<div>11111111111</div>
		<div>22222222222</div>
		<div>33333333333</div>
	</div>
</body>
</html>

After the button is clicked I try to sort elements in 'frm' frame, but the behavoir of them is realy wierd. For example I need to drag items out of the frame's bounds to see that something is changed.

(jqueryui is 1.7.2, jquery 1.3.2)

Changed December 01, 2010 12:01PM UTC by MrPete comment:4

I believe this ticket is the key issue preventing use of jQuery UI in GreaseMonkey.

(I would provide a link but akismet doesn't seem to like me)

Changed December 01, 2010 12:02PM UTC by MrPete comment:5

An indirect link: http://jsbin.com/urame4

Changed October 20, 2011 04:29PM UTC by scottgonzalez comment:6

#7803 is a duplicate of this ticket.

Changed October 20, 2011 05:11PM UTC by scottgonzalez comment:7

milestone: 1.next → 1.9
status: new → open

See also #7801.

Changed October 11, 2012 02:57PM UTC by scottgonzalez comment:8

milestone: 1.9.0 → 1.10.0

Changed December 28, 2012 10:36AM UTC by jzaefferer comment:9

The widget factory provides window and document properties. Once all widgets make consistent use of those, this issue should resolved.

Places where document is accessed directly:

  • jquery.ui.core: scrollParent() and zIndex() use document
  • datepicker (no use of widget factory)
  • draggable
  • effect. and effect-transfer
  • mouse
  • position, for the fraction support test
  • resizable
  • sortable

Places where window is accessed directly:

  • datepicker
  • dialog, the position.of property defaults to window
  • draggable
  • position, for the default within:window
  • sortable
  • spinner, to access Globalize

Changed January 25, 2013 01:57PM UTC by scottgonzalez comment:10

resolution: → fixed
status: open → closed

Closing fixed as the majority of cases have been handled. The remaining should be covered in the remaining rewrites. Any other issues should be reported as individual bugs.