FAQ Topic - How do I access a frame's content? (2009-10-25)
in [JavaScript]
|
Prev: Implicit object constructor misinterpretation
Next: Creating an Object that extends Array functionality
From: Dr J R Stockton on 28 Oct 2009 19:38 In comp.lang.javascript message <hc85ms$v4c$1(a)news.eternal- september.org>, Tue, 27 Oct 2009 17:10:48, Garrett Smith <dhtmlkitchen(a)gmail.com> posted: >> <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. 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. -- (c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Proper <= 4-line sig. separator as above, a line exactly "-- " (SonOfRFC1036) Do not Mail News to me. Before a reply, quote with ">" or "> " (SonOfRFC1036)
From: VK on 28 Oct 2009 20:30 Dr J R Stockton wrote: > >> In effect, I want to read the file, HTML or TXT, as it exists on disc. VK wrote: > >You cannot do it for the reason explained at > >http://groups.google.com/group/comp.lang.javascript/msg/d9f3f6724bada573 Dr J R Stockton wrote: > 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.
From: Garrett Smith on 28 Oct 2009 23:18 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. f.contentDocument.body.textContent will (where available). Hopefully that clears up any potential ambiguity. >> 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. > Where available, CharacterData is a often a good option. It is widely supported in modern browsers as: aTextNode.data -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/
From: Thomas 'PointedEars' Lahn on 29 Oct 2009 05:51 Garrett Smith wrote: > 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. >>> 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. > > 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 -- Anyone who slaps a 'this page is best viewed with Browser X' label on a Web page appears to be yearning for the bad old days, before the Web, when you had very little chance of reading a document written on another computer, another word processor, or another network. -- Tim Berners-Lee
From: Garrett Smith on 29 Oct 2009 14:22
Thomas 'PointedEars' Lahn wrote: > Garrett Smith wrote: > >> 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. 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? 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). This led to misfortunate confusion, and a diverted side-track discussion of IFRAME element vs frame. If you want to make a proposal, try a basic solution-based approach: e.g. observed problem -> possible approaches to fix -> proposal something like: The FAQ has/does not mention [x] Problems related to [x] come up frequently. [x] should be mentioned in the FAQ I propose [x] be be added to the FAQ in the following way: [short suggestion] It does not have to be super-formal or strictly follow a format. Recent comments from G Talbot, for example, were very helpful. Those comments were assertive and to the point; not lame; not whining. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |