Closed Bug 64017 Opened 24 years ago Closed 24 years ago

Iframe's contentDocument is implemented incorrectly.

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

VERIFIED INVALID

People

(Reporter: netdragon, Assigned: jst)

Details

(Keywords: testcase)

Attachments

(6 files)

The DOM specifies iframe.contentDocument as type Document, but Mozilla returns it as type HTMLDocument. Furthermore, when you try to access it(read-only) using document or HTMLDocument methods, it doesn't work. For instance if you wanted to do: document.getElementByID ("IframeID").contextDocument.documentElement.addEventListener ("load",function_load, true); to... say... access the iframe's document. http://www.w3.org/TR/2000/REC-DOM-Level-2-Core-20001113/ http://www.w3.org/TR/2000/WD-DOM-Level-2-HTML-20001113/html.html If everything is a node, then the things included in the attachment(will attach later) should work (I think). contentDocument should be readonly.
Attached file Use this testcase instead please (deleted) —
If you run this testcase (#2) you should see that it returns type HTMLDocument. HTMLDocument is different than type Document. Then it acts as if what it returns has no properties. It is read only but should be able to be read.
Verified Platform: PC OS: Linux 2.2.16 Mozilla Build: 2000122808 M18 Trunk Build Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Adding Testcase keyword.
Keywords: testcase
updating component
Assignee: asa → jst
Component: Browser-General → DOM Level 2
QA Contact: doronr → vidur
Fist of all, HTMLDocument is a interface, or class if you will, that inherits the Document interface, thus a HTMLDocument is a Document. iframe.contentDocument will return the document object in the iframe, if that's a HTML document then iframe.contentDocument will be a HTMLDocument (you get the automatic conversion in JavaScript, that's why it looks like it's not directly a Document object), please have a look at http://lxr.mozilla.org/seamonkey/source/dom/public/idl/html/HTMLIFrameElement.idl#16 for the definition of the contentDocument property on HTMLIFrameElement objects. The reason your testcase isn't able to access the document in the iframe is because of the security restrictions in mozilla (same as they are for frames in framesets in all browsers), since the testcase comes from bugzilla.mozilla.org and the content of the iframe is from www.mozilla.org the testcase is not alowed to access properties on the document in the iframe, for that to work both the testcase and the content of the iframe need to come from the same host, or alternatively you could use document.domain to alow access from other domains. If you have the JavaScript Console open you'll see that there are JavaScript errors in the testcase and that is due to access not being alowed to the properties you're trying to access. The error message you get on the console is incorrect tho, it should say "Access denied..." but there's no error message so that is a problem, I don't see a problem with the contentDocument property on iframes in your testcase. Marking INVALID, I filed bug 64126 on the incorrect error message.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Notice the test case I just submitted. In bugzilla.mozilla.org and www.mozilla.org (the same domain as the file is on), loading doesn't cause the event to happen in the page that contains the iframe. In fact, there is no way to detect clicks in a frame thats on a different site in the current security model. That is no good because one cannot make a fake browser ;-)
Attached file iframe content (deleted) —
The term "domain" in the DOM spec really means host, bugzilla.mozilla.org is a different "domain" than www.mozilla.org, have a look at the testcase I just attached (the last attachment), both the file and the iframe content come from bugzilla.mozilla.org are the outer page is able to access iframe.contentDocument w/o problems. document.domain can be used to get around this security restriction if you're building a website...
Sorry. I am just a bit confused. I see that, but why can't a page know when an Iframe loads? That isn't a security risk is it? I don't even understand how this addeventlistener works. It is defined in the DOM and in the Node idl file, but it is only part of the event interface. But isn't that what is sent with the event itself?
I was confused because addEventListener was defined in a seperate interface as node but people used it as a member of node. I read in the DOM that it was some kind of cast binding. I believe the attachment I attached should work because there are no security issues involved - both files are on the same host. Furthermore, I believe a page has a right to know when its iframe is fully loaded. If one thinks about the iframe as analogous to a body, or frameset (I don't know if the DOM gives it events that way) shouldn't it have an onload and onunload defined? Also, when you capture click events from the frame, it only captures those on the border of the frame. Doesn't a page have a right to know if the user is clicking in the frame? The page doesn't have to know where the user clicked, just that they did click.
Also, notice that placing the event in the document inside the iframe only and not on the iframe itself doesn't even allow the page that contains the iframe to know that the page has changed. For instance: If a site had its navigation on a page and loaded the rest of the site on an iframe in that page, the site might want to unload the navigation if someone makes the iframe load a different site, and reload the new site in the browser window. They could never do that the way things are.
The reason your latest testcase doesn't work is that it sets the onload handler of the document in the iframe in the onload handler of the containing document. It seems like you expect that the onload handler for the iframe will fire when a new document is loaded into the iframe, but that's not how it works, the onload handler that you set on the document in the iframe is bound to that document only, when the document in the iframe changes the iframe is "reset" so that variables defined in the old frame (or window) are cleared and this is also intentionally done for event handlers, and the document is of course replaced with the new document. Because of this the onload handler you set on the document never fires since it is (intentionally) cleared before the new document is loaded. In general, in a document that contains a frame/iframe the rule is when the document loads the onload handlers for the child frames are fired *before* the onload handler for the container document is fired. But when the container document is loaded and a new document is loaded into a child frame dynamically sometime after the document is fully loaded there's no notification to the containing document when the child frame is loaded. Assuming you have access to the document in an iframe you can set an onunload handler on the document and you'll be notified when the document goes away but there's currently no way for the containing document to know when the new document is loaded into the iframe. There's currently an open RFE bug on adding support for onload/onunload handlers on frames/iframes but there's no work being done in this area at this time (bug 60173).
verying
Status: RESOLVED → VERIFIED
Component: DOM Level 2 → DOM Other
Component: DOM Other → DOM Level 1
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: