Accessing remote window HTML elements via getElementsByTagName, Problems accessing remote window HTML elements via getElementsByTagNam Options

[ArtK]

Hello, I am trying to access HTML DOM elements in a remote window using
JavaScript and getElementsByTagName but the resultant arrays are undefined.
<pre>
var remoteWin = window.open(URL,'rmtWindow');
remoteTags = remoteWin.document.getElementsByTagName("<tag>");
localTags = document.getElementsByTagName("<tag>");
</pre>
This works fine for localTags but not for remoteTags.
Am I not referencing the remote window correctly?

Also there seems to be some inconsistency in returned values:
<pre>
<a href="href URI string" param="hvalue"><img src="img URI string" param="ivalue"></a>
getElementsByTagName("a") returns the full "href URI string" string but
getElementsByTagName("img") returns "[object HTMLImageElement]"
</pre>
I want to retrieve and manipulate the actual text strings of these elements,
i.e., I want to access "img URI string", "hvalue" and "ivalue".
I assume that I need to access properties of "[object HTMLImageElement]"
to obtain the strings, including the strings for the optional parameter
strings, but where or how do I find the definition of these properties?

Is there a way to associate the returned value for each embedded "img" element
with its encapsulating "a" element? It is highly unlikely that the array indicies
will match.

Thank you for your help, Art

This post has been edited by ArtK: Aug 17 2009, 04:47 PM

[pandy]

What do you mean when you say a window is remote? Does it load a page from another domain?

Also, it's 'document.getElementsByTagName("tag")', but maybe that was a mistake when you wrote the code here.

[ArtK]

What do you mean when you say a window is remote? Does it load a page from another domain?

Also, it's 'document.getElementsByTagName("tag")', but maybe that was a mistake when you wrote the code here.

A remote window, such as pop-up window, is a window that is separate, distinct and independent from the local or "in focus" window. The "local" window is where this code resides, the one that opened the "remote" window. It has its own DOM tree and, hence, requires a different name than the local or "self" window.

Look at the code:

"document.getElementsByTagName" is only for the local window, not the remote window.
To retrieve elements from a remote window reference requires a different name.

[Christian J]

I recommend not using popups, since browsers may use popup blockers.

This was much harder than when doing similar things between frames, for some reason (or maybe I'm complicating things). Try this in the parent page:

CODE

<script type="text/javascript">
window.open('popup.html', '_blank');
function test(c)
{
    alert(c);
}
</script>

...and this in the popup:

CODE

<h1>Header text</h1>
<script type="text/javascript">
window.onload=function()
{
    opener.test(document.getElementsByTagName('h1')[0].innerHTML);
}
</script>

Note that the function test() in the parent page is called from the popup, that way you can make sure the popup has loaded before the function is called.

Also note that security reasons may prevent browsers from reading or writing between pages hosted on different domains.

[ArtK]

I recommend not using popups, since browsers may use popup blockers.

This was much harder than when doing similar things between frames, for some reason (or maybe I'm complicating things). Try this in the parent page:

CODE

<script type="text/javascript">
window.open('popup.html', '_blank');
function test(c)
{
    alert(c);
}
</script>

...and this in the popup:

CODE

<h1>Header text</h1>
<script type="text/javascript">
window.onload=function()
{
    opener.test(document.getElementsByTagName('h1')[0].innerHTML);
}
</script>

Note that the function test() in the parent page is called from the popup, that way you can make sure the popup has loaded before the function is called.

Also note that security reasons may prevent browsers from reading or writing between pages hosted on different domains.

Christian, Thanks for your response.

Let me say that this is a local client side app, similar to a widget, so I should have complete control over my browser options (except that Firefox does not want to follow instructions). I find that using a browser that supports Javascript and remote windows enables me to create many useful little apps that would be very difficult if not impossible to do in a text editor, even a text editor with macros. Even though Javascript cannot save the output to disk directly, it is very easy to save the target window manually.

For this app, I want to be able to load an arbitrary page into the remote window so modifying it or embedding code is not an option. The direction of control or access will always be from the local or "self" window to the remote window.

I have found that using remote windows is actually easier than using frames. Using frames requires a minimum of two files to keep synchronized whereas with named remote windows everything can be self contained in a single file. Most of the time I neither need nor want the output on the same page. Separate browser windows (tabs), increases the screen space and gives me more flexibility such as saving the output.

Actually, the only difference between frames and separate browser windows is one line of code:

var remoteWindow = window.open(url);

vs

var remoteWindow = parent.frameName; parent.frameName.location=url;

Subsequent code accessing "remoteWindow" doesn't care whether it is a frame window or a browser window. (Usually. There seems to be a difference in direct DOM element access. Frames are giving me a problem.]

Your comment about cross domain access restrictions motivated me to check out that possibility and that turns out to be the problem! (It had crossed my mind earlier but did not stick.) Even using the DOM element arrays remoteWindow.document.anchors[] and remoteWindow.document.images[] to access the remote window has the same roadblock.

[One "gotcha" that I found: the DOM anchors[] arrays only contains anchor elements that have a NAME ATTRIBUTE! The element array generated via getElementsByTag("a") does include all anchor elements, whether or not they have a name attribute.]

So now the problem becomes: how do I enable cross domain access in a browser?
(I only need read access, not write access.)

I realize this goes against the grain of the current security thrust of browser operation but there are legitimate needs for this ability. IE (shudder), has a cross domain switch but it does seem to have any effect. Firefox and Opera do not seem to have any relevant menu options but there may be something in about:config. Configuration options for Safari and Chrome are non-existent or a joke. Any ideas or suggestions???

BTW: I strongly recommend that you bookmark:

http://www.w3schools.com/default.asp
http://www.w3schools.com/htmldom/dom_reference.asp.

It is a giant site with a wellspring of useful web developer resources, not the least of which is a complete list of all HTML elements and their properties and methods.

[Darin McGrew]

There is a reason why browsers make cross-site scripting difficult:
http://en.wikipedia.org/wiki/Cross-site_scripting

[Christian J]

So now the problem becomes: how do I enable cross domain access in a browser?
(I only need read access, not write access.)

With PHP (at least in some configurations) you can read files from other domains with the file_get_contents() function, so you might be able to copy the content from a remote page into your current one, and use JS on the copy as necessary.

[pandy]

BTW: I strongly recommend that you bookmark:

http://www.w3schools.com/default.asp
http://www.w3schools.com/htmldom/dom_reference.asp.

It is a giant site with a wellspring of useful web developer resources, not the least of which is a complete list of all HTML elements and their properties and methods.

Just be aware that w3schools' information is sometimes disinformation. They are not always correct.

[ArtK]

Just be aware that w3schools' information is sometimes disinformation. They are not always correct.

That may be true but can you name a single thing in this world, let alone the internet, that is 100% accurate? What I found was a site with a huge, huge amount of useful information in a well laid out, easy to use format. I did not find any mistakes in what I already knew, (the HTML elements and attributes that I checked matched the W3C spec, including the deprecations) and it gave me the new information that I needed. It even noted that the HTML DOM anchors array does NOT include anchor tags without a name attribute, unlike the getElementsByTagNames Javascript method, which does. Why un-named anchors were left out makes no sense but it does prove that even the official W3C organization can make mistakes! That one little piece of info will save me many, many hours of frustration and hair pulling.

[ArtK]

There is a reason why browsers make cross-site scripting difficult:
http://en.wikipedia.org/wiki/Cross-site_scripting

Yes, I am quite aware of cross scripting vulnerabilities but I really see no point in picking my own wallet. As I tried to make clear this is for a locally run app - to be run by me on a single computer, on a single desktop, processing local files. Malware is NOT an issue here.

[ArtK]

So now the problem becomes: how do I enable cross domain access in a browser?
(I only need read access, not write access.)

With PHP (at least in some configurations) you can read files from other domains with the file_get_contents() function, so you might be able to copy the content from a remote page into your current one, and use JS on the copy as necessary.

Perhaps, but that would really complicate a simple problem as well as require another language. That would be like raising the bridge instead of releasing some air out of the truck tires.

I think my problem is solved: There is a way to temporarily remove the cross domain access restriction is a safe manner. So now I should be able to create the simple app that I had envisioned.

Thanks for your help.

[Christian J]

There is a way to temporarily remove the cross domain access restriction is a safe manner. So now I should be able to create the simple app that I had envisioned.

How did you do it, by modifying the browser?

[pandy]

Yes, I am quite aware of cross scripting vulnerabilities but I really see no point in picking my own wallet. As I tried to make clear this is for a locally run app - to be run by me on a single computer, on a single desktop, processing local files. Malware is NOT an issue here.

How is the browser supposed to know that? And how is it a cross domain issue if all files are local?

[Christian J]

getElementsByTagName("a") returns the full "href URI string" string

Didn't follow that. document.getElementsByTagName("a") returns a collection/array of all A elements. If you want the HREF value of one of them, try

CODE

document.getElementsByTagName("a")[i].href

(where "i" is the array's index number).

getElementsByTagName("img") returns "[object HTMLImageElement]"

Again you need to specify a particular IMG element in the array, and then look for its attribute value(s).

I want to retrieve and manipulate the actual text strings of these elements

Elements don't have text strings in the DOM. They do have attributes and attribute values, though, and a text node can be a child node of an element.
If you want to regard an element as a string, you might use the innerHTML property, but you can't apply DOM functions to such a string (use string functions instead).

i.e., I want to access "img URI string", "hvalue" and "ivalue".
I assume that I need to access properties of "[object HTMLImageElement]"
to obtain the strings, including the strings for the optional parameter
strings, but where or how do I find the definition of these properties?

If you're not sure which attributes an element contains, you might examine them with the attributes array. See http://www.javascriptkit.com/dhtmltutors/domattribute2.shtml

Is there a way to associate the returned value for each embedded "img" element
with its encapsulating "a" element? It is highly unlikely that the array indicies
will match.

You might list all IMG elements inside each A element with a second loop:

CODE

var a=document.getElementsByTagName('a');
for(var i=0; i<a.length; i++)
{
    var img=a[i].getElementsByTagName('img');
    for(var j=0; j<img.length; j++)
    {
        alert(img[j].src);
    }
}

[Christian J]

Just be aware that w3schools' information is sometimes disinformation. They are not always correct.

That may be true but can you name a single thing in this world, let alone the internet, that is 100% accurate? What I found was a site with a huge, huge amount of useful information in a well laid out, easy to use format. I did not find any mistakes in what I already knew, (the HTML elements and attributes that I checked matched the W3C spec, including the deprecations) and it gave me the new information that I needed. It even noted that the HTML DOM anchors array does NOT include anchor tags without a name attribute, unlike the getElementsByTagNames Javascript method, which does. Why un-named anchors were left out makes no sense but it does prove that even the official W3C organization can make mistakes! That one little piece of info will save me many, many hours of frustration and hair pulling.

According to http://www.w3.org/TR/DOM-Level-2-HTML/html.html#ID-7577272 anchor is indeed a

"collection of all the anchor (A) elements in a document with a value for the name attribute"

I don't consider that a mistake by W3C, instead it's a way to define named anchors like the second A element here:

CODE

<a href="#foo">Link to Foo</a>
...
<a name="foo">Foo</a>

Rather it's http://www.w3schools.com/HTMLDOM/dom_obj_anchor.asp that gets it wrong by saying:

"The Anchor object represents an HTML hyperlink.

For each instance of an <a> tag in an HTML document, an Anchor object is created."

without mentioning that NAME attributes are required.