User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:18.104.22.168) Gecko/20060124 Firefox/22.214.171.124
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:126.96.36.199) Gecko/20060124 Firefox/188.8.131.52
Steps to Reproduce:
1. Download AJAX for Dummies companion code from http://media.wiley.com/assets/1002/24/ajaxcode.zip
2. unzip the code into a directory accessible both via local filesystem and via httpd
3. using either mozilla or firefox, attempt to load file://<localfs_loc>/ch02/index.html
4. After page "Ajax at work" loads, click the "Display Message" button. Observe no changed text.
5. Using same browser as above, load "http://<host>/ch02/index.html
6. After page "Ajax at work" loads, click the "Display Message" button. Observe one line of changed text.
The page fails to change content: the line "The fetched data goes here" should change to "This text was fetched using Ajax".
The page should change content.
Created attachment 216125 [details]
File in question
This is the file in question.
"Error: syntax error
Source File: file:///C:/Documents%20and%20Settings/mw22/Bureaublad/ajaxcode/ch02/data.txt
Line: 1, Column: 1
This text was fetched using Ajax. "
When I remove the && XMLHttpRequestObject.status == 200 check from the file, then the script works just fine.
IE6 works just fine, so it seems like a bug to me in Mozilla.
Ah wait, when loading files locally with xmlhttprequest, you don't get a status returned probably, because you're not on a webserver.
need file data.txt in same directory as index.html. File should have a single line without tags reading:
This text was fetched using Ajax.
Sorry to make you fetch the file; if I ever have another issue I'll do it myself .
I interpret that you are stating that a status is not returned
if the file was fetched using a base href starting file:// whereas a status is returned if the file was fetched using http://
So from my uneducated (know nothing about Mozilla/Firefox internals) vantage, there are two possibilities:
b) The localized pseudo-webserver built into Mozilla for handling base URLs beginning file:// is broken and is not returning a status when it should.
(In reply to comment #2)
> Ah wait, when loading files locally with xmlhttprequest, you don't get a status
> returned probably, because you're not on a webserver.
(In reply to comment #4)
> b) The localized pseudo-webserver built into Mozilla for handling base URLs
> beginning file:// is broken and is not returning a status when it should.
It's debatable that the file:// protocol handler should do that. It's not a web server; it's simply an interface to your local filesystem, just the same as ftp:// shouldn't return HTTP status codes.
I suggest that XMLHttpRequest should either work differently (i.e. no statuses, although I can't see the effectiveness of this) or not at all with protocols other than http://.
(In reply to comment #5)
The status placed into the XMLHttpRequest object is 0 if it successfully loads a local file, but 200 if it successfully loads a webserved file. Why different success states due only to URL content?
And I didn't know the returned status was also zero for ftp:// GET requests. This is getting interesting.
(In reply to comment #6)
> (In reply to comment #5)
> The status placed into the XMLHttpRequest object is 0 if it successfully loads
> a local file, but 200 if it successfully loads a webserved file. Why different
> success states due only to URL content?
> And I didn't know the returned status was also zero for ftp:// GET requests.
> This is getting interesting.
Because they're using different protocols. You don't use HTTP for fetching local or FTP files, so any stuff related to HTTP when working with such files has to be hacked around.
I've asked on news.mozilla.org, and I believe this is intentional.
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #5)
I thought XMLHTTPRequest was supposed to screen where stuff comes from in terms of protocol. It actually makes no sense to differentiate where a page came from in terms of status, if the engine is going to treat the content identically in spite of origin. Someone here posted that they had tested this under IE and IE returns a 200. I realize that IE is the ENEMY in some sense, but every once in a while, IE gets it right, particularly when we have to add more code for no real gain doing it the Mozilla way, which reveals implementation details about where the page came from. I'm impressed the way someone punted this by converting this to "RESOLVED INVALID". I'm not going to start a war by clicking the "reopen bug" button, but I am going to say I'm pretty disappointed in you guys.
The reason I opened this bug is because I have a course I give to 3rd and 4th graders at the local elementary school on HTML. The paradigm is for each student to develop their "myspace" website locally using only the students' webbrowsers (which to date have been Netscape/Mozilla/Firefox), and then to post the completed work to the district website. I decided this term to add AJAX to the mix. Now I don't have the time to port the various AJAX frameworks I'm reviewing so they work locally under Gecko, and my kids certainly wouldn't understand how to do so at home after my class. IE gets the nod from hereon because I don't have to touch any AJAX framework to get it to work locally under IE. I've graduated approximately 100 Netscape/Mozilla/Firefox 3rd and 4th graders each year for the past 10 years; many of these kids (now college age) had only seen IE and had no idea any other browser existed. I'm sad for what I must now do, but I've got no choice. Cheers.
Resolving a bug as invalid doesn't mean the matter's finished. In fact in hindsight, I think I might've done so prematurely.
For reference, the news.mozilla.org thread: http://groups.google.com/group/mozilla.dev.ajax/browse_thread/thread/0ffb0e899cd404ff/c02ece139b6eed9a#c02ece139b6eed9a
(The referenced thread says that we try to follow the IE implementation, so if it returns 200, we probably should do that too.)
Resummarizing the bug according to comments 1 and 6.
By the way, the attached file is probably a wrong one, there's no mention of .status there.
Created attachment 216422 [details]
File in question
Sorry, I must have removed it while testing. This is the original file.
For testing, you also need to have a data.txt file for testing.
Hmm, IE returns 0 as well for me.
Argh, I'm terribly sorry. I must have my testing mixed up (I must have tested with the wrong testcase in IE6).
IE6 now also returns 0 for me.
So I guess this bug is indeed invalid. Mozilla is already doing the same as IE6 here.
I had a similar experience (FireFox 184.108.40.206), when tried with non-existent URL
FireFox displays unable to connect but XMLHttpRequest simple crashes (no errors in console, no exceptions raised) when tried to access property "status".
I've posted the code here: