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.

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.

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

Retarget all enhancements/features to next major version.

Reset priority to low, per triage docs

How common is this use-case?

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.

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.

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.