Bug Tracker

Opened 13 years ago

Closed 9 years ago

#1124 closed enhancement (wontfix)

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, Rick Waldron
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)

jquery-1.3.2+1124.patch (4.1 KB) - added by ecmanaut 10 years ago.
Patch towards jquery-1.3.2.js, implementing #1124

Download all attachments as: .zip

Change History (10)

comment:1 Changed 12 years ago by john

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 10 years ago by ecmanaut

Attachment: jquery-1.3.2+1124.patch added

Patch towards jquery-1.3.2.js, implementing #1124

comment:2 Changed 10 years ago by ecmanaut

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.

comment:3 Changed 10 years ago by john

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.

comment:4 Changed 9 years ago by snover

Milestone: 1.4.41.5

Retarget all enhancements/features to next major version.

comment:5 Changed 9 years ago by Rick Waldron

Priority: majorlow

Reset priority to low, per triage docs

comment:6 Changed 9 years ago by snover

Keywords: needsreview added

How common is this use-case?

comment:7 Changed 9 years ago by anonymous

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.

comment:8 Changed 9 years ago by addyosmani

Cc: dmethvin snover Rick Waldron added

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.

comment:9 Changed 9 years ago by dmethvin

Keywords: needsreview removed
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.

Note: See TracTickets for help on using tickets.