Closed
Bug 64017
Opened 24 years ago
Closed 24 years ago
Iframe's contentDocument is implemented incorrectly.
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
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.
Reporter | ||
Comment 1•24 years ago
|
||
Reporter | ||
Comment 2•24 years ago
|
||
Reporter | ||
Comment 3•24 years ago
|
||
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.
Comment 4•24 years ago
|
||
Verified
Platform: PC
OS: Linux 2.2.16
Mozilla Build: 2000122808 M18 Trunk Build
Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•24 years ago
|
||
updating component
Assignee: asa → jst
Component: Browser-General → DOM Level 2
QA Contact: doronr → vidur
Assignee | ||
Comment 7•24 years ago
|
||
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
Reporter | ||
Comment 8•24 years ago
|
||
Reporter | ||
Comment 9•24 years ago
|
||
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 ;-)
Assignee | ||
Comment 10•24 years ago
|
||
Assignee | ||
Comment 11•24 years ago
|
||
Assignee | ||
Comment 12•24 years ago
|
||
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...
Reporter | ||
Comment 13•24 years ago
|
||
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?
Reporter | ||
Comment 14•24 years ago
|
||
Reporter | ||
Comment 15•24 years ago
|
||
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.
Reporter | ||
Comment 16•24 years ago
|
||
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.
Assignee | ||
Comment 17•24 years ago
|
||
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).
Updated•24 years ago
|
Component: DOM Level 2 → DOM Other
Updated•24 years ago
|
Component: DOM Other → DOM Level 1
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•