Bug Tracker

Opened 12 years ago

Closed 12 years ago

Last modified 11 years ago

#7779 closed bug (invalid)

$(xml).children() behaves differently depending if it's loaded locally or on a web server

Reported by: [email protected] Owned by:
Priority: undecided Milestone: 1.6
Component: unfiled Version: 1.4.4
Keywords: Cc:
Blocked by: Blocking:


This being my first bug report, please be gentle if it is either missing information or due to something on my end.

I was build a menu with UL and LI elements by recursively traversing an XML file generated externally. This worked fine locally, it displayed all the menu items and then applied superfish to it for displaying.

When I uploaded it to my webhost however (and even with local XAMPP install), it stopped working correctly. After some help from the jQuery forums and a lot of headaches, the following "bug" game to light:

When loading an XML file through an ajax call (either .ajax or .get) and retrieving the number of children of the root element through $(xml).children().length , the "root" is different depending on whether the file is opened on the hard drive or through a URL. Through a URL it seems to see the "document" (xml file/top/whatever), while locally it sees the actual root element in the XML.

It's not possible to reproduce this on jsfiddle simply because I'm externally loading the xml file (it seems to work fine when defining XML as a string variable with the contents being the xml itself). So I placed this on the web and separated it from my website design. URL is here: http://www.chromocode.ca/jqueryxmlrootbug/

To see the different locally, save the html and XML file on your drive in the same folder, and double-click on the html file. The "undefined" element should be gone. (note: for some odd reason RockMelt, based on chrome, couldn't load the menu locally whatever I did, not sure why)

Current workaround: Calling $(xml).children().children() for the first element, which works on the website but not when loading locally.

Change History (3)

comment:1 Changed 12 years ago by [email protected]

My apologies for the grammar mistakes, I am very much a #fail at reviewing my own text :P

  • "I built a menu with..."
  • "the following bug came to light..."
  • "to see the difference locally..."

About my chrome note: maybe it's more than that - IE fails locally also, but doesn't display any error message. Please try using Firefox, it's the only one that will correctly display it locally. Remotely, all of FF, IE and Chrome work fine.

comment:2 Changed 12 years ago by jitter

Resolution: invalid
Status: newclosed

Thanks for taking the time to contribute to the jQuery project by writing a bug report and providing a test case!

After reading your report and looking at your test case I determined that this isn't a jQuery bug. Did you try looking at the parameter you get in your processXml callback? When working locally it is a string (in most browsers), when working remote it is a XML document. This is the key to your problems.

When loading the file locally from your harddrive (of course) there are no headers present and what happens depends on browser/os. Loading the file from remote the webserver passes the correct headers telling the browser this a xml file. This way jQuery "automagically" figures out that this is XML and returns you a XML document.

To get consistent behavior just use the optional dataType parameter to the get function

$.get("Toc.xml", parseXML, "xml");

and you should be set.

comment:3 Changed 12 years ago by [email protected]

Well, I did ask around before I posted this and 3 people had no clue. As they say in the ghettos (or do they?): You the man, man!

Thank you very much, jitter!

Note: See TracTickets for help on using tickets.