Skip to main content

Bug Tracker

Side navigation

#1124 closed enhancement (wontfix)

Opened April 13, 2007 07:27PM UTC

Closed December 31, 2010 09:34PM UTC

Please extend the document ready function to include document object in another frame

Reported by: daemach Owned by:
Priority: low Milestone: 1.5
Component: event Version: 1.4
Keywords: frames ready Cc: dmethvin, snover, rwaldron
Blocked by: Blocking:
Description

I would like to be able to use $(top.frames[n].document).ready(function(){}) in addition to the standard document ready. The ability to optionally apply any functions passed to the document object in that frame would be handy, but the default would be to attach to the window.document object as it does now.

Attachments (1)
Change History (9)

Changed July 15, 2007 03:15PM UTC by john comment:1

milestone: 1.1.31.1.4
resolution: → wontfix
status: newclosed
version: 1.1.21.1.3

Having a document ready across frames isn't possible in any sort of practical capacity. The best that I can recommend is to bind a 'load' listener to an Iframe so that you can be notified when it's ready for use.

Changed August 08, 2009 03:03AM UTC by ecmanaut comment:2

resolution: wontfix
status: closedreopened

I am not sure I understand the closing remarks, but as we needed $(any_doc).ready(callback) to work for another document than the one jQuery gets loaded into, and the attached patch seems to work just fine -- is there a chance it could get into jQuery?

I wasn't sure whether jQuery.isReady was considered an official API meaning "the current document is ready", but in case it is, remove the commented-out sections after the two NOTE: if official API, uncomment these two lines comments, to keep such semantics intact.

A test case of what we needed it for (a document in an iframe needing to know both when it's loaded itself, and when its parent document is) is available at http://bushong.net/dave/jquery-1124/ (both the parent window and the iframe take a few seconds to load, flush():ing so the HTML gets to the client, tempting it to render its DOM early).

It works beautifully in Firefox 3.0 and 3.5 (mac, linux and windows), IE 7 and 8 (XP), Safari 4 (mac) and opera 10.00 beta 2 (mac), probably others too.

Changed December 05, 2009 02:39AM UTC by john comment:3

component: coreevent
milestone: 1.1.41.5
version: 1.1.31.4

This is a good patch - I think we'll try to tackle it for post-1.4.

Changed October 19, 2010 01:07AM UTC by snover comment:4

milestone: 1.4.41.5

Retarget all enhancements/features to next major version.

Changed October 22, 2010 06:28PM UTC by rwaldron comment:5

priority: majorlow

Reset priority to low, per triage docs

Changed November 22, 2010 07:10AM UTC by snover comment:6

keywords: frames readyframes ready needsreview

How common is this use-case?

Changed November 22, 2010 01:07PM UTC by anonymous comment:7

I need/needed it.

I have a bookmarklet and browser plugin that run javascript on a site I do not control directly. Both the bookmarklet and the browser plugin load jQuery and add some features to the site in question. When the site opens pop-ups, I need to interact with them, but it's currently difficult to do so since I can't easily tell when the pop-up document is ready.

For the time being I am using a polling solution, watching for certain elements to appear in the dom -- this solution is pop-up specific though and isn't so reliable.

Changed December 05, 2010 06:18AM UTC by addyosmani comment:8

cc: → dmethvin, snover, rwaldron

Having reviewed your use case, I don't believe that this is something which we would consider all that widespread. That said, as John initially mentioned, the patch created was quite good and it's usefulness may be worth a further discussion regarding whether we do indeed include this or not.

I am cc'ing some of my colleagues on this ticket for further input having received a response from the ticket submitter.

Changed December 31, 2010 09:34PM UTC by dmethvin comment:9

keywords: frames ready needsreviewframes ready
resolution: → wontfix
status: reopenedclosed

Any cross-frame accesses run afoul of both security and memory-leak issues.

It seems like a great situation for someone to write a "frames" plugin that handled all these cases so that the non-frame users don't have to pay the penalty in size and complexity.