3

Possible Duplicate:
Chrome: Disable same origin policy

so a little background information about my issue:

  • Writing a JavaScript file for a gallery; pulling data from an xml file, here.
  • Loading the DOM Object with XMLHttpRequest(), using async loading.
  • Parsing the responseText with a DOMParser to make a DOM object.
  • Works on FireFox, fails on Chrome.

EDIT (Please read):

After using console.log, it seems that Chrome is reporting a Cross-Origin Issue:

  • Failed to load resource file: ./Gallery/dropdown_style.css
  • XMLHttpRequest cannot load file: ./Gallery/gallery_info.xml. Cross origin requests are only supported for HTTP.
  • NodeList[0]
  • length: 0
  • Uncaught Error: NETWORK_ERR: XMLHttpRequest Exception 101
  • Failed to load resource ./Gallery/Pictures/bg_one.jpg

Now my questions are:

  1. How do I fix this on the local level (offline)?
  2. Will this still be a problem even if I upload all the files to the same server?
  3. If so, what's the solution for that as well (online)?

Now the DOM Object comes through, presumably correct on both Firefox and Chrome. And in the following code:

window.alert(xmlDoc.getElementsByTagName("pic"));

It returns with the response of "HTML Collection" or, in Chrome, "NodeList". But when I ask for that NodeList's length in Chrome, it returns 0, meaning that the NodeList is formatted incorrectly, or not as I had intended.

In FireFox, the length will return a value of 2, which IS what I had intended.

Here is my source code, without the excess jargon:

var elemPic = [];

function initGallery(xmlFName){

    var xmlhttp = new XMLHttpRequest();
    xmlhttp.open("GET", xmlFName, true);
    xmlhttp.onreadystatechange = function(){
        if (xmlhttp.readyState == 4){ //since it's offline and local, don't check status == 200
            //use a DOMParser, which is in a different file
            myCallBack(parseXml(xmlhttp.responseText));
        }
    }
    xmlhttp.send();
}

function myCallBack(xmlDoc){
    //window.alert(xmlDoc);
    elemPic = xmlDoc.getElementsByTagName("pic");
    //window.alert(elemPic);

    for(var i = 0; i < elemPic.length; i++){
        //whats the source path?
        var src = elemPic[i].getElementsByTagName('src')[0].childNodes[0].nodeValue;
        window.alert(src);
    }
}

And here's my entire source folder, if you want to see it: Source Folder

I'm not sure which of the problems this is:

  1. DOM xml Object is corrupt
  2. NodeList is corrupt
  3. Overarching Chrome issue with getElementsByTagName()
  4. Other

If you guys could help me identify the exact source of the problem, and the solution, then I would very grateful.

Community
  • 1
  • 1
jhwg
  • 31
  • 3
  • 1
    Try using console.log. It actually prints out the contents of objects, including NodeList, which is why it's recommended over window.alert for debugging. – Luminously Nov 19 '12 at 22:25
  • I'll give that a shot, thanks. – jhwg Nov 19 '12 at 22:27
  • Well, whaddya know, it looks like it was a Cross-Origin error, on local access. – jhwg Nov 19 '12 at 22:32
  • So now my question is: How do I fix this on the local level? Will this also be a problem if uploaded to a server? – jhwg Nov 19 '12 at 22:34
  • You need to serve the file from a local web server. – Diego Pino Nov 19 '12 at 22:37
  • Hmm okay I can do that, but if I left the code unchanged, but uploaded it all to a server, would there still be a Cross-Origin issue? – jhwg Nov 19 '12 at 22:43
  • @jwg: No, the error should not happen any more after uploading. To allow local file access via XHR for testing, you can set this via Chrome's command line options. – Bergi Nov 19 '12 at 22:46
  • Replace `parseXml(xmlhttp.responseText)` with [`xmlhttp.responseXML`](https://developer.mozilla.org/en-US/docs/DOM/XMLHttpRequest#responseXML) – Bergi Nov 19 '12 at 22:47
  • 1
    If you serve it from a local web server there won't be Same Origin policy issue. Another way of open the file without setting up a web server is to start Chrome as $ google-chrome --disable-web-security – Diego Pino Nov 19 '12 at 22:47
  • @Everyone: Great, thanks! I'll give both a try when I can and respond with results. – jhwg Nov 19 '12 at 22:49
  • @Bergi: xmlhttp.responseXML gave me a null, instead of an XML Object. I did not check it with console.log, but I don't think it worked with FireFox when I tried it. – jhwg Nov 19 '12 at 22:50
  • @jwg: Sure, that's a) prevented by the same-origin-policy or b) because your XML is invalid or served with incorrect MIME type – Bergi Nov 19 '12 at 22:52
  • @Bergi: Ah, that would make sense. I have seen the MIME fix all over StackOverflow when I tried to find an answer for my issue. I'll probably try that, rather than having to tediously parse the text. – jhwg Nov 19 '12 at 22:55
  • close as duplicate of [Chrome: Disable same origin policy](http://stackoverflow.com/questions/3102819/chrome-disable-same-origin-policy) or [Problems with jQuery getJSON using local files in Chrome](http://stackoverflow.com/questions/2541949/problems-with-jquery-getjson-using-local-files-in-chrome) – Bergi Nov 19 '12 at 23:09
  • PLease don't put 'solved' in your title. If you have an answer, you should add it as such. It does not belong in your question. – George Stocker May 13 '13 at 12:10

1 Answers1

0

The Answer: Looks like the issue was with the Same-Origin Policy. For local access, upload the file to a local web server, or change Chrome settings for testing purposes. There should be no problem if uploaded to a server.

Big thanks to users Luminously, Diego Pino, and Bergi.

Steps to solving the problem:

  1. Use console.log() instead of window.alert() - it's so much more detailed and accurate.
  2. Local: Upload file to local web server OR Change Chrome Settings (disable web security)
  3. Global: No problems if uploaded to a server.
jhwg
  • 31
  • 3