Closed Bug 15119 Opened 25 years ago Closed 25 years ago

FEATURE: Implement script based mechanism for loading an XML document and manipulating it via DOM interfaces


(Core :: XML, enhancement, P3)






(Reporter: nisheeth_mozilla, Assigned: nisheeth_mozilla)


(Keywords: helpwanted)

I'm putting this RFE in the bug system to track a feature that seems an
important addition to our current XML functionality.

Here's the email from Steve Muench at Oracle who suggested this feature:

>Is there now (I have downloaded M8) an equivalent set of features in Mozilla
>accessibile from javascript that would let me:
>   (1) Construct an instance of an XML Document
>   (2) Load/parse an HTTP-based URL to a "source" of XML
>   (3) Walk the DOM tree in the browser?

CCing Vidur.

I'm currently scheduling this for post-beta work.  Will try to bring it in more
if time permits.
Target Milestone: M15
Whiteboard: HELP WANTED
Adding Tim Bray's comments for future reference:

Subject: Re: mozilla finally
Date: Fri, 12 Nov 1999 18:42:34 -0800
From: Tim Bray <>

At 02:22 PM 11/12/99 -0800, you wrote:
>a mechanism for loading XML data
>from a URL via script. Both Nisheeth and I would like to talk to you at some
>point about an optimal way to implement that. IE solves some of the problem
>with XML islands and, I believe, also includes a mechanism for directly
>invoking a parser. We'd like to see how we can expose this functionality in as
>standards compliant a way as possible.

Hmm... I don't know of a standard that applies in this case.  Dom level
27 is supposed to have this stuff, right?  In the interim, is the
MS way hopelessly botched?  If not, why not just copy it?  A nice
add-on would be to expose a SAX interface for those cases where
the XML might be real big and you don't want to blow your memory. -T.
Severity: normal → enhancement
OS: Windows NT → All
Keywords: helpwanted
Whiteboard: HELP WANTED
In addition to a URL, a string (Javascript String) as a valid XML source would
be convenient.

I fiddled about with the IE  XML islands approach in the current
MOzilla (M14) build, to see what effect islands in existing documents
would have on the Mozilla HTML parser and renderer. There are some 
potential problems, which I outline below. 

At present, the Mozilla HTML parser will process an XML 'island' 
elements (and content) as 'unknown' HTML, and converts the data 
into usable data in the HTML 'tree'. This is sort of like the
IE 5 island - the data is just in the wrong place.
Howeover, there is a problem with the  handling of existing
islands. This is because the HTML parser can't handle empty-element
tags in an island, which means that elements are not closed properly. 
This problem is illustrated by the file:
which uses the script at

to write out an HTML doc listing some info about the document's
tree structure -- note how wonky it is. THis will break _any_ DOM
script on the page, even if the script doesn't use the island data.

This also means that you can't reliably use CSS to 'hide' an island,
since the XML element may not be properly ended.

Obviously this is not a critical problem (well, I wasn't able to
crash M14 with my tests), but this is worth trying to fix, if this
issue is actually handled.

The only obvious solution I can see is to mimic the IE approach, by 
hard-wiring the <XML> ... </XML> element to a special handler that 
removes the content from the HTML parser,and either discards it or
redirects it to an XML parser.  
This would make my life easier, so we are tracking it for Zope Studio.
Keywords: zopestudio
Cc:ing myself and I strongly feel that mozilla without the

ability to load external XML from JS considerably limits the functionality/

flexibility that mozilla can offer to content/application developers.

I think this is a really important feature.

Let's take the discussion about what kind of XML functionality we want to the 
new newsgroup, news://netscape.public.mozilla.xml

That will be easier to read and will keep this rfe from being cluttered up.
Moving bugs out by one milestone...
Target Milestone: M15 → M16
non-essential for m16
Target Milestone: M16 → M17
Many people (including but not limited to me :) ) thinks this is an important 
feature, and since M16 is supposed to be feature-compleate shouldn't this be 
*** Bug 35234 has been marked as a duplicate of this bug. ***
Bringing in to M16...
Target Milestone: M17 → M16
*** Bug 35234 has been marked as a duplicate of this bug. ***
It would be extremely useful (and future-proof) if the actual HTTP request 
could take the form of a GET *or* a POST request.

In a typical (XML-RPC and SOAP come to mind) case the request message will 
consist of XML as well. Since GET url strings have limited carrying capacity, 
POST is the only way to send XML documents/trees of medium (say 2K+) size.

If a possibility is provided to send string/XML using POST, there should be a 
method to add custom HTTP headers, for instance "HTTP_CONTENT_TYPE:text/xml". 
All the form clunk and "x-www-form-urlencoded" mess is not welcome...

Basically, I'd like this object/component to have the functionality of ie5's 
XmlHttpRequest. Of course you wouldn't *need* to pass anything, just an URL to 
load XML would be enough.

XmlHttpRequest methods&properties:
The fix for this is checked in.  See my post titled "Support for loading an XML 
document from script" in netscape.public.mozilla.xml.
Closed: 25 years ago
Resolution: --- → FIXED
*** Bug 31331 has been marked as a duplicate of this bug. ***
I would like to ask for a synchronous loading function as well.

This makes sense in a lot of cases and should not be too hard to add.
QA Contact: chrisd → petersen
Marking verified per last comments.
You need to log in before you can comment on or make changes to this bug.