FAQ Topic - How do I access a frame's content? (2009-10-25)

[FAQ server]

-----------------------------------------------------------------------
FAQ Topic - How do I access a frame's content?
-----------------------------------------------------------------------

To reference another frame on the _same domain_:

A frame's content window can be found from the ` frames ` collection.

Example:

var fwin;
fwin = self.frames[0]; // or:
fwin = self.frames["iframeName"];

or from the ` IFRAME ` or ` FRAME ` element:

var iframeEl = document.getElementById("myFrame");
var fwin = iframeEl.contentWindow;

An identifier ` moomin ` in the the iframe's content window,
is accessed as ` fwin.moomin `.

To communicate between frames on _different_ domains:

Where supported, (IE8, Firefox 3, Opera 9, Safari 4), use
` window.postMessage( message[, port], otherDomain); `.

Example:

http://jibbering.com/faq/example/postMessage.html

Where ` window.postMessage ` is not supported, the ` window.name ` property
can be set on the other window, which can poll for updates to that
property using ` setInterval(checkWinName, 100); ` where ` checkWinName `
is a function that polls to check the value of
` self.name `.

http://en.wikipedia.org/wiki/Same_origin_policy

http://www-archive.mozilla.org/docs/dom/domref/dom_frame_ref5.html

https://developer.mozilla.org/en/DOM/window.postMessage

http://msdn.microsoft.com/en-us/library/cc197015(VS.85).aspx


The complete comp.lang.javascript FAQ is at
http://jibbering.com/faq/

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]

, Sat, 24 Oct 2009 23:00:02, FAQ server <[email protected]> posted:

or from the ` IFRAME ` or ` FRAME ` element:

var iframeEl = document.getElementById("myFrame");
var fwin = iframeEl.contentWindow;

Perhaps it is worth subdividing, for clarity :

How do I access the content of a frame or iframe

Domain considerations

Frame

Iframe



I've been accessing a page in an iframe with
<iframe>.contentDocument.body.innerHTML // FF Op Sf Cr
<iframe>.contentDocument.body.innerText // Not Firefox?
but I there have no interest in accessing variables. Using IE8, the
code fails at an earlier stage.

In effect, I want to read the file, HTML or TXT, as it exists on disc.


QUERY : disregarding unlikely server & browser settings, which
extensions are taken to imply that the file can safely be read into an
iframe and parsed or read textually there?
(a) HTM HTML SHTML
(b) TXT
(c) *not* ZIP EXE GIF, for example.

 

[VK]

In effect, I want to read the file, HTML or TXT, as it exists on disc.

You cannot do it for the reason explained at
http://groups.google.com/group/comp.lang.javascript/msg/d9f3f6724bada573

To read HTML as it exists on disc you have to either
i) read it over a plain text editor on the computer in question
ii) read it as text input stream by using AJAX request.

Anything else simply generates a request to the browser parser to read
the existing DOM Tree resulted from the original page and to back-
parse it to HTML code by the match rules of this particular parser.
The results normally are as an Old Slavonic being translated to
Mandarin and from Mandarin to English by a Spanish native speaker.

QUERY : disregarding unlikely server & browser settings, which
extensions are taken to imply that the file can safely be read into an
iframe and parsed or read textually there?

see above

 

[Dr J R Stockton]

In comp.lang.javascript message <963d3089-ac6c-47a7-8fec-e2f5f3617de5@l3
4g2000vba.googlegroups.com>, Sun, 25 Oct 2009 17:00:29, VK

You cannot do it for the reason explained at
http://groups.google.com/group/comp.lang.javascript/msg/d9f3f6724bada573

Unconvincing, because I *am* doing it, to the extent that is essential
for the task. If you consider under what circumstances what can work,
you should be able to deduce how and why I am doing it.

To read HTML as it exists on disc you have to either
i) read it over a plain text editor on the computer in question

i.i) use TYPE or MORE at the command line
i.ii) read it with a text viewer

ii) read it as text input stream by using AJAX request.

Anything else simply generates a request to the browser parser to read
the existing DOM Tree resulted from the original page and to back-
parse it to HTML code by the match rules of this particular parser.

Note, though, that "want" can mean more than "need".

I want to read as on disc, certainly; but my needs are substantially
satisfied for TXT files by what innerText and innerHTML show, and for
HTML files by what is actually revealed.

It's annoying that Firefox seems to lack innerText of iframe content, so
that the output of innerHTML has to be used and purified before use.


FYI, the unanswered "missing page" detection which I raised on
2009-10-15 is now fully dealt with.


DQS

 

[Thomas 'PointedEars' Lahn]

I want to read as on disc, certainly; but my needs are substantially
satisfied for TXT files by what innerText and innerHTML show, and for
HTML files by what is actually revealed.

It's annoying that Firefox seems to lack innerText of iframe content,

It implements the `textContent' property instead, like any other browser
standards-compliant in that regard. (Discussed here ad nauseam).

Suppose `iframe' refers to the object implementing the HTMLIFrameElement
interface, then you are looking for

iframe.contentDocument.documentElement.textContent

That is, if the layout engine (like Gecko) wraps the content of a text/plain
resource in a markup (HTML-like) document. More precise would be

iframe.contentDocument.body.textContent

then. I remember to have posted that explanation before, but the FAQ had
not been updated for some reason.

so that the output of innerHTML has to be used and purified before use.

Non sequitur.


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,
Tue, 27 Oct 2009 19:38:40, Thomas 'PointedEars' Lahn

It implements the `textContent' property instead, like any other browser
standards-compliant in that regard. (Discussed here ad nauseam).

I see. Then why did you not suggest that <FAQENTRY> it should be
included in the frame-content section (9.2) of the FAQ? It's still
annoying that one major browser lacks what others have (even if out of
fashion), especially if the functionality is present.

Suppose `iframe' refers to the object implementing the HTMLIFrameElement
interface, then you are looking for

iframe.contentDocument.documentElement.textContent

That is, if the layout engine (like Gecko) wraps the content of a text/plain
resource in a markup (HTML-like) document. More precise would be

You should know better than to suggest, or appear to suggest, writing
engine-dependent code in the default Web context.

iframe.contentDocument.body.textContent

then. I remember to have posted that explanation before, but the FAQ had
not been updated for some reason.

Yes, the FAQ maintainer clearly does not understand how the job should
be done. If a change is worth making (and there is either no doubt or a
reasonable consensus), then it is worth making immediately.



<FAQENTRY> FAQ 9.7 : ISTM that there may be another cause, or a
refinement of that one. Firefox 3.0.14 gives me "Permission denied to
get property HTMLDocument.anchors" on approximately the 150th time of
doing what seems to be essentially the same thing

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]>,
Tue, 27 Oct 2009 19:38:40, Thomas 'PointedEars' Lahn


I see. Then why did you not suggest that <FAQENTRY> it should be
included in the frame-content section (9.2) of the FAQ? It's still
annoying that one major browser lacks what others have (even if out of
fashion), especially if the functionality is present.



You should know better than to suggest, or appear to suggest, writing
engine-dependent code in the default Web context.

The innerText/textContent is not related to the frame; its' related to
elements. The frame is a window.

As I've stated before, neither are available in Blackberry9000.

Yes, the FAQ maintainer clearly does not understand how the job should
be done. If a change is worth making (and there is either no doubt or a
reasonable consensus), then it is worth making immediately.



<FAQENTRY> FAQ 9.7 : ISTM that there may be another cause, or a
refinement of that one. Firefox 3.0.14 gives me "Permission denied to
get property HTMLDocument.anchors" on approximately the 150th time of
doing what seems to be essentially the same thing

I'm busy with several different edits to the FAQ and have not gotten to
a good stopping point.

Did you post an example of code that causes the error?

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn posted:

I see. Then why did you not suggest that <FAQENTRY> it should be
included in the frame-content section (9.2) of the FAQ?

Because I do not think it is a frequently asked question.

It's still annoying that one major browser lacks what others have (even if
out of fashion), especially if the functionality is present.

Which browser would that be?

You should know better than to suggest, or appear to suggest, writing
engine-dependent code in the default Web context.

No, because I am aware of the concept of graceful degradation supported by
feature-testing. You should know better than to assume that I would
recommend to use this code untested.

Yes, the FAQ maintainer clearly does not understand how the job should
be done. If a change is worth making (and there is either no doubt or a
reasonable consensus), then it is worth making immediately.
ACK

<FAQENTRY> FAQ 9.7 : ISTM that there may be another cause, or a
refinement of that one. Firefox 3.0.14 gives me "Permission denied to
get property HTMLDocument.anchors" on approximately the 150th time of
doing what seems to be essentially the same thing

SOP?


PointedEars

 

[Garrett Smith]

Thomas 'PointedEars' Lahn posted:

[snip]

Yes, the FAQ maintainer clearly does not understand how the job should
be done. If a change is worth making (and there is either no doubt or a
reasonable consensus), then it is worth making immediately.

ACK

If there is another reason for complaining, it has not been provided.

I've heard the complaint about innerText/textContent not being mentioned
in relation to frames and replied.

As I explained, the innerText/textContent is not related to the frame;
it is related to elements. An entry on getting frame's
innerText/textContent implies that a frame has a property
innerText/textContent. That would be false.

 

[Thomas 'PointedEars' Lahn]

The innerText/textContent is not related to the frame; its' related to
elements. The frame is a window.

The (i)frame window is represented by a Window instance; the `iframe'
element is not (AISB). Apparently you still need to learn the difference
between element objects and other host objects.

As I've stated before, neither are available in Blackberry9000.

Negligibly small Blackberry market share¹ notwithstanding, that is not
a good reason for ignoring any of the presented solutions at all.
That is, provided it is a frequently asked question to begin with.


PointedEars
___________
¹ <http://stats.getjar.com/statistics/world/manufacturer/BlackBerry>

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Tue, 27 Oct 2009 17:10:48, Garrett Smith

I'm busy with several different edits to the FAQ and have not gotten to
a good stopping point.

Do and release one at a time. Forget those version numbers - just date
it (in ISO 8601).

Did you post an example of code that causes the error?

No. It's on the Web, within
<URL:http://www.merlyn.demon.co.uk/linxchek.htm> (about 915 lines) at
current line 346 or 351, early in function ReadDOC() and marked. It is
now known to be connected with trying to load into the frame a page
which is in a subdirectory rather than in the current directory.

The problem is not seen in MSIE8 because it never gets that far; and is
not seen in Opera, Safari & Chrome which are happy and proceed to the
end.

There is now an input control "GoUp" which enables reading subdirectory
pages, default 1 but 0 if Firefox is detected; that for me substantially
alleviates the problem, since most of the work is in the current
directory. Also Chrome is very much faster : Chrome 25s, Firefox 112s.

Now that it is known what causes it, a simpler example can be attempted.

FWIW, In Opera an attempt to load into an iframe
a copy of the current page hangs. Ditto, Self.

Both in XP sp3.

Firefox 3.0.15 is available, also 3.5.4.

3.5.4 does the same.


In the same page : LINXCHEK.HTM will not load LINXCHEK.HTM (i.e. itself)
into its iframe in Firefox & Opera, but it will in Safari & Chrome.
MSIE8 fails earlier. Control "Self" deals with that similarly.

 

[VK]

Unconvincing, because I *am* doing it,

You don't, it is your delusion.

to the extent that is essential
for the task.  If you consider under what circumstances what can work,
you should be able to deduce how and why I am doing it.

I don't know how and why are you doing it, but it was stated that "I
want to read the file, HTML or TXT, as it exists on disc." As long as
you are not using AJAX calls - and you don't - you are not able and
you are not reading any files "HTML or TXT, as it exists on disc" -
however wide the definition "as it exists on disc" would be taken.
What are you doing is sending requests to the browser to parse the DOM
tree resulted from the loaded source and to convert the nodes back to
the source using back-conversion rules supplied with the given
browser. The difference can be small, huge or a completely different
document - but never equal to the one that "exists on disc".
To help you to visualize it here a sample file that say exists on disc
as test.html with the textual content
<BODY onLoad="alert(document.documentElement.innerHTML)">
<P>Lorem ipsum
<P>Dolor sit amet
</BODY>

This very file in Geck becomes (I have Skype add-on installed):

<head>
<script
charset="utf-8"
id="injection_graph_func"
src="chrome://skype_ff_toolbar_win/content/injection_graph_func.js">
</script>
</head>
<body onload="alert(document.documentElement.innerHTML)">
<p>Lorem ipsum
</p><p>Dolor sit amet
</p></body>

and on IE (using outerHTML instead of innerHTML):

<HTML> <HEAD> </HEAD>
<BODY onload="alert(document.documentElement.innerHTML)">
<P>Lorem ipsum
<P><p>Dolor sit amet </P> </BODY> </HTML>

If the latter two variants do correspond to your definition of "as it
exists on disc" then I am highly amazed.

As much as I can understand you request, you want to get the textual
data from the loaded document in full and without omission which is
doable but it is a completely different task.

 

[Garrett Smith]

[...]

The innerText/textContent is not related to the frame; its' related to
elements. The frame is a window.

The (i)frame window is represented by a Window instance; the `iframe'
element is not (AISB). Apparently you still need to learn the difference
between element objects and other host objects.

For those who did not notice that I wrote "the frame", and not the
IFRAME element.

Assuming a document with an iframe:

var f = document.getElementsByTagName("iframe")[0];
f.textContent;

- will not get the text content inside the iframe's document.

f.contentDocument.body.textContent

will (where available).

Hopefully that clears up any potential ambiguity.

Negligibly small Blackberry market share¹ notwithstanding, that is not
a good reason for ignoring any of the presented solutions at all.
That is, provided it is a frequently asked question to begin with.

Where available, CharacterData is a often a good option. It is widely
supported in modern browsers as:

aTextNode.data

 

[Thomas 'PointedEars' Lahn]

The (i)frame window is represented by a Window instance; the `iframe'
element is not (AISB). Apparently you still need to learn the difference
between element objects and other host objects.

For those who did not notice that I wrote "the frame", and not the
IFRAME element.

Assuming a document with an iframe:

var f = document.getElementsByTagName("iframe")[0];
f.textContent;

- will not get the text content inside the iframe's document.

Of course not; it will get the (alternative) text content of the element
node. Nobody has ever implied otherwise.

f.contentDocument.body.textContent

will (where available).

Hopefully that clears up any potential ambiguity.

Your evading the issue is unsuccessful. Just to remind you: Your
justification for not adding this to the FAQ was that `textContent'
"is not related to the frame", which is ridiculous.

Where available, CharacterData is a often a good option. It is widely
supported in modern browsers as:

aTextNode.data

s/option/alternative/

Whether it is a good alternative remains to be seen because `data' accesses
only the data of *one* text node at a time, while `textContent' accesses
*all* children text nodes of an element at once.


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>,
Wed, 28 Oct 2009 21:01:01, Thomas 'PointedEars' Lahn

Because I do not think it is a frequently asked question.

Then why did you not suggest that the section be removed?

Which browser would that be?

With a little more - with any - humility and/or common sense, you would
read what you quote both before and after composing a reply. The answer
to that question is plainly visible above, currently at the >>>> level.
Matthew 7:7, Luke 11:9.

Those verses, with their nexts, could be put in the FAQ as a
sort of motto - safely, were it not for the TL effect.

SOP?

OAF.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
september.org>, Wed, 28 Oct 2009 12:16:06, Garrett Smith

As I explained, the innerText/textContent is not related to the frame;
it is related to elements. An entry on getting frame's
innerText/textContent implies that a frame has a property
innerText/textContent. That would be false.

In a FAQ, answers should be classified according to the nature of the
question, not according to the nature of the answer.

A common reasoning for questioning is that the answer is not where the
questioner thought to look.

In ordinary English, a frame, or at least an iframe, does commonly have
an innerText or textProperty property; but it is kept by one of its
descendants.

Ask the average elderly person whether they have grandchildren.
Commonly the answer will be "Yes"; it will not be "No; but I have
children who have children".

Anyway, the FAQ said "9.2 How do I access a frame's content?", rightly
omitting any reference to the structure within the frame.

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn posted:

Then why did you not suggest that the section be removed?

Because I was not aware of its existence to date (obviously I never had a
problem that required searching the comp.lang.javascript FAQ for it), and
because I am not absolutely certain that it is not a frequently asked
question. It is just my impression that it is not, but I may have missed
some questions (definitely those posted with standards-violating `From'
header).

With a little more - with any - humility and/or common sense, you would
read what you quote both before and after composing a reply. The answer
to that question is plainly visible above, currently at the >>>> level.

I have asked before because that implication of yours would be incorrect.
Firefox/Gecko does not lack what others have; IE/MSHTML does lack it. While
probably not in number of installations, `textContent' is the standards-
compliant approach which is supported by more current layout engines than
`innerText' is or is going to be.

Matthew 7:7, Luke 11:9.

Those verses, with their nexts, could be put in the FAQ as a
sort of motto - safely, were it not for the TL effect.

So much for "humility and/or common sense".

OAF.

Sorry, I am not familiar with that acronym, and it is not listed on
<http://www.merlyn.demon.co.uk/acronyms.htm#Acro> or in the usual places.


PointedEars

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
Garrett Smith wrote:
Dr J R Stockton wrote:
Thomas 'PointedEars' Lahn posted:
iframe.contentDocument.body.textContent

then. I remember to have posted that explanation before, but the
FAQ had not been updated for some reason.
The innerText/textContent is not related to the frame; its' related to
elements. The frame is a window.
The (i)frame window is represented by a Window instance; the `iframe'
element is not (AISB). Apparently you still need to learn the
difference between element objects and other host objects.
For those who did not notice that I wrote "the frame", and not the
IFRAME element.

Assuming a document with an iframe:

var f = document.getElementsByTagName("iframe")[0];
f.textContent;

- will not get the text content inside the iframe's document.

Of course not; it will get the (alternative) text content of the element
node. Nobody has ever implied otherwise.

f.contentDocument.body.textContent

will (where available).

Hopefully that clears up any potential ambiguity.

Your evading the issue is unsuccessful. Just to remind you: Your
justification for not adding this to the FAQ was that `textContent'
"is not related to the frame", which is ridiculous.

If you want to make a proposal, then do so.

I need to know first if it is a FAQ to begin with. In any case, I have made
the potential proposal already.

The proposal was:

| I see. Then why did you not suggest that <FAQENTRY> it should be
| included in the frame-content section (9.2) of the FAQ?

Is this the issue I evaded?

No, the issue that you are evading is that the approach using `textContent'
is a possible and useful answer to this question.

As I stated, textContent is not related to the frame; stating otherwise,
as the proposal for section (9.2) "9.2 How do I access a frame's
content?" would be misleading (counterproductive to FAQ goals). [...]

No, it would not. `text*Content*' clearly addresses the issue of accessing
a frame's *content*.


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <e317ec92-048b-4d6d-be38-ce3e14a5933a@j4
g2000yqe.googlegroups.com>, Wed, 28 Oct 2009 17:30:34, VK

You don't, it is your delusion.


I don't know how and why are you doing it, but it was stated that "I
want to read the file, HTML or TXT, as it exists on disc." As long as
you are not using AJAX calls - and you don't - you are not able and
you are not reading any files "HTML or TXT, as it exists on disc" -
however wide the definition "as it exists on disc" would be taken.

Give or take irrelevant questions of character coding and newline
representation, I have been getting, by using innerHTML and by using
innerText, a string which agrees visually with the content of a TXT file
on disc, as would be shown by Notepad.

I still WANT to read a HTML file correspondingly, seeing the source
lines as per Notepad; but I don't really NEED to, since what I can get
suffices for that part of the desired work that is NECESSARY.

As much as I can understand you request, you want to get the textual
data from the loaded document in full and without omission which is
doable but it is a completely different task.

Yes, that is what I still WANT. But it is more than, in the case of an
HTML page, I really NEED. Therefore progress is being made.



Associated query : I have read a TXT file from disc, getting a matching
string. It consists of many lines containing words separated by
punctuation. They all start with the same sequence of words and
punctuation (improbably, zero length), but after that there is always
non-zero length. No two lines completely agree. What is the nicest way
of determining the common part AND obtaining in sequence strings for the
varying parts? Think of it as like a representation of a directory
tree.

 

[Garrett Smith]

In comp.lang.javascript message <[email protected]
september.org>, Wed, 28 Oct 2009 12:16:06, Garrett Smith


In a FAQ, answers should be classified according to the nature of the
question, not according to the nature of the answer.

A common reasoning for questioning is that the answer is not where the
questioner thought to look.

In ordinary English, a frame, or at least an iframe, does commonly have
an innerText or textProperty property; but it is kept by one of its
descendants.

The IFRAME element and the frame (as in frames[0] or
anIframe.contentWindow), are different.

It is important to be clear on the distinction. These are technical
terms, not ordinary English terms.

Ask the average elderly person whether they have grandchildren.
Commonly the answer will be "Yes"; it will not be "No; but I have
children who have children".

So what?

Anyway, the FAQ said "9.2 How do I access a frame's content?", rightly
omitting any reference to the structure within the frame.

The "content" would be in the document.