Closed Bug 302622 Opened 19 years ago Closed 19 years ago

Using eval() on JavaScript returned from XMLHttpRequest call throwing errors

Categories

(Firefox :: General, defect)

x86
Windows 2000
defect
Not set
major

Tracking

()

VERIFIED INVALID

People

(Reporter: ryan.asleson, Unassigned)

References

()

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+

Deer Park Alpha 2 on Windows 2000 is complaining about "syntax error" errors in
the JavaScript console when attempting to eval() JavaScript that is returned
from the responseText property of the XMLHttpRequest object. This must be a
regression because it works flawlessly in Firefox 1.0, IE, Opera, and Safari.
The JavaScript should be absolutely correct so I don't know what Deer Park is
complaining about. The same exact problem also appears in Mozilla Suite
2005070205 on Windows 2000.

Reproducible: Always

Steps to Reproduce:
1.  Visit http://taconitetest.thunderboltsoftware.com/ .

2.  Open the JavaScript console and clear it of all errors/warnings.

3.  Click the first button on the page.

4.  After a second or two, a row will be added to the table, which is good. 
However, look at the JavaScript console. It's complaining about a syntax error
in the JavaScript.

5.  Scroll to the bottom of the page. There you'll see a window showing the
JavaScript. Inspect the JavaScript and you'll see that it is all valid JavaScript.

6.  All of the tests on the page work like they're supposed to (although each
one throws a syntx error in the JS console) EXCEPT the last test on the page,
the Performance Test. This one doesn't create a table like it is supposed to.

Actual Results:  
Deer Park Alpha 2 complains about a syntax error in the JavaScript, even though
it is all valid JavaScript.

Expected Results:  
The JavaScript should run and update the page as written without throwing any
syntax errors in the JS console.

Here's what's happening under the covers.  Each time a button is clicked an
XMLHttpRequest request is sent the server. The server responds by sending a
bunch of JavaScript to update the contents on the page. When the XMLHttpRequest
object receives the server response, it runs eval() on the responseText property
of the XMLHttpRequest object. Running eval() on the entire responseText should
simply execute the JavaScript returned by the server to update the web page.

The JavaScript sent by the server is always displayed at the bottom of the page.

Please note that this runs flawlessly, without producing any errors, in Firefox
1.x, IE, Opera, and Safari, so there must be something screwy in newer builds of
Gecko.

Dynamic page editing using XMLHttpRequest and JavaScript is only getting more
popular, so this functionality needs to work.

Thank you!!
This is a XML parsing error but not a JavaScript parsing error.
The content  requested by XMLHttpRequest is served as text/xml,
but it is not valid XML document.

http://65.29.9.61:8084/taconite-test/appendAsChildrenTest.jsp
--
GET /taconite-test/appendAsChildrenTest.jsp HTTP/1.0

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=98406B1EAF2B93EAC1C86EFF0614966B; Path=/taconite-test
Content-Type: text/xml;charset=ISO-8859-1
Content-Length: 694
Date: Fri, 29 Jul 2005 14:03:50 GMT
Connection: close

    var element0 = document.createDocumentFragment(); (...omit...)
--

This content must be served as text/plain. It is a server's problem.
OK, I see.  I changed it on my local server and that fixed it, thanks.  The
reason is was set to text/xml in the first place is that I've heard reports that
older versions of Mozilla freeze up if the content-type of the response to an
XMLHttpRequest request is something other than text/xml.  Changing it to
text/plain works in Firefox 1.x, Deer Park, IE, and Opera -- have to wait to
test Safari.

Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.