311724 - JavaScript Console reports XML syntax error whenever XMLHttpRequest is used with an XML mime type and non-XML content

Status: RESOLVED INVALID

(Core :: XML, defect)

Description

[wechsler]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051006 Firefox/1.4.1

Whenever an xmlHttpReq object is sent, an error appears in the javascript
console, which suggests that the javascript engine is trying to execute the
fetched page as javascript code.

Eg - for the above URL, taken from the mozilla developer area (info in example
page source):

Error: syntax error
Source File: http://gene.sentinel3.phase.org/test.txt
Line: 1, Column: 1
Source Code:
Hello World^

Similar problems occur at the URL http://gene.sentinel3.phase.org/ajax.html
which is a reduced case triggered from a clean HTML file.

False errors like this take a whole lot of wasted debugging time! 

The errors do not appear in Firefox 1.0.6 on the same machine.

Reproducible: Always

Steps to Reproduce:
1. Open and clear the Javascript console
2. Go to either of the above test URLs
3. Click the text
4. Clear the alert box (on the nsajax example)
5. Check the Javascript console for a new error

Actual Results:  
An error similiar to the following is flagged in the javascript console:
Error: syntax error
Source File: http://gene.sentinel3.phase.org/test.txt
Line: 1, Column: 1
Source Code:
Hello World^

Or, where an attempt is made to fetch a file containing only: 
'alert("Hello World");'
the error is
Error: not well-formed
Source File: http://gene.sentinel3.phase.org/test.txt
Line: 1, Column: 6
Source Code:
alert("Hello World");-----^


Expected Results:  
No error should have been flagged. In the nsajax.html case an alert box should
appear; in the ajax.html no result should be visible.

OSX 10.4.2
  Machine Name:	PowerBook G4 12"
  Machine Model:	PowerBook6,4
  CPU Type:	PowerPC G4  (1.2)
  Number Of CPUs:	1
  CPU Speed:	1.33 GHz
  L2 Cache (per CPU):	512 KB
  Memory:	768 MB
  Bus Speed:	167 MHz

Comment 1

[wechsler]

Attachment: Clean XHTML text case

Calls test.php (uses POST method, required a PHP file on this server)

Comment 2

[wechsler]

Attachment: File called by ajax.html

Comment 3

[wechsler]

Attachment: Test case, copied from developer.mozilla.org example code

Taken from 
http://developer.mozilla.org/en/docs/AJAX:Getting_Started#Step_3_.E2.80.93_.22All_together_now.21.22_-_A_Simple_Example

as an example of known good code

Comment 4

[wechsler]

Attachment: Used by nsajax.html

Comment 5

[wechsler]

Attachment: File called by ajax.html

File 198965 was wrong file - uploaded in error!

Comment 6

[Adam Guthrie]

I have a feeling this has something to do with how you're serving (or not having
a doctype or something in) text.txt.

Comment 7

[Jesse Ruderman]

This line of the testcase tells Firefox to treat the response as XML:

        xmlHttpReq.overrideMimeType('text/xml');

When Firefox gets the response, it tries to treat it as XML and reports an XML
syntax error when it fails to parse it.  You can tell that this is an XML
parsing error rather than a JavaScript error by comparing the error messages
generated by these two data URLs:

        data:text/xml,report|OK
        data:text/html,<script>report|OK</script>

This could be fixed by:

A) Fixing the example on the wiki to not override the mime type.  (When is it
necessary to override the mime type?  Do you have to use an XML mime type to
make .responseXML work?)

B) Making Firefox not report XML syntax errors unless you use .responseXML.

C) Making Firefox not even try to parse the XML until you use .responseXML.

See also bug 302622, you're not the only person confused by this.

Bug 243089 might be related.

Comment 8

[wechsler]

Thanks Jesse - I've created a couple of text cases where XML datatypes are not
overridden or set, (using text/plain instead). The error does not arise in this
case, in either Firefox 1.5b2 or 1.06 -

http://gene.sentinel3.phase.org/ajax2.html
http://gene.sentinel3.phase.org/nsajax2.html

This may mean that this is notabug in Firefox, but in the vast majority of AJAX
documentation online. I'll see what I can do about contacting people in charge
of such documentation.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I think it's reasonable to report an error when we're told to parse something as
XML and can't... If we didn't, it would be much much harder to debug cases where
eg the server is not returning what you think it is.

It sounds like the only real bug here is that the error console is still
misnamed "Javascript console".

As for when overriding the type is needed, it's needed any time you expect to
want the DOM and aren't sure the server will send the data with an XML type.

Comment 10

[Jesse Ruderman]

Why does Gecko use the mime type (set by the server or a JavaScript override) to
determine whether to try to generate a DOM rather than, say, only generating the
DOM the first time the script actually accesses responseXML?  (See (C) in 
comment 7.)

Comment 11

[Boris Zbarsky [:bzbarsky]]

I suspect this was done partly because it was easy to both pump data into the
parser and to stash in in our responseText.  But it also has the side benefit
that once an async XMLHttpRequest is done, getting the responseXML doesn't
freeze up while it tries to parse the whole thing.

Some data on how often people do or don't want the responseXML would also help
here.  If they usually want it, parsing eagerly is the way to go.

Comment 12

[Jesse Ruderman]

*** Bug 322120 has been marked as a duplicate of this bug. ***

Comment 13

[Boris Zbarsky [:bzbarsky]]

This is invalid.

Comment 14

[Dave Townsend [:mossop]]

*** Bug 342137 has been marked as a duplicate of this bug. ***

Comment 15

[Sventek]

can you try please with this : in text.txt ===> Test lève épaules ümläutö rêve ?

you can test it here :

http://maroc.flash.free.fr/httprequest_test.html

Comment 19

[John J. Barton]

Just in case some else hits this...

If you execute a XHR from a file URL, the MIME mapping is different than a server URL. 
https://developer.mozilla.org/En/How_Mozilla_determines_MIME_Types#ExternalHelperAppService

So JS applications that work perfectly fine from a server generate the subject error message when run from the file system.

In our specific case we tried to load a dojo app from the filesystem for a test suite. Every dojo file load (lots of them) gives the error message.

To overcome this problem you have to explicitly set the MIME type
req.overrideMimeType('text/plain');