XMLHttpRequest::onload should fire even when no XML content is returned

RESOLVED WORKSFORME

Status

()

P3
normal
RESOLVED WORKSFORME
18 years ago
16 years ago

People

(Reporter: taras.tielkes, Assigned: hjtoi-bugzilla)

Tracking

Trunk
mozilla0.9.5
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
Hi Vidur, some feedback on error handling in the XmlHttpRequest component.

It looks like the current code is designed towards handling XML only. There is 
no "responseText" method to get the result text (which may or may not be XML).

http://bugzilla.mozilla.org/show_bug.cgi?id=49572

Another thing is the handling of HTTP errors, especially 404's. At the moment, 
there is no way to cache these. The IE5 solution is very simle: it's equivalent 
of "onload" will fire when the HTTP transfer is complete, with the HTTP status 
code and status text available.

To summarize, this is the chain of events I would expect:
(1) call to send()
(2) set resultText property + HTTP result code/text
(3) if result is valid xml, set responseXML property
(4) fire onload, regardless of the question if the respnse if XML
(Reporter)

Comment 1

18 years ago
The 6th line in the comment should of course read ".. catch these ..."
(Reporter)

Comment 2

18 years ago
Ack. And the last line should be "... if the response is XML.".
Hmm... I am not sure if we should fire the "load" event. "error" might seem more
appropriate, but not sure...
(Reporter)

Comment 4

18 years ago
Hmm... Heikki, the IE5+ implementation will fire onload when the HTTP 
connection is "done". "done" also means HTTP errors, like a 404.

That's where the "status" and "statusText" properties come in. Checking for 
common HTTP results is trivial. I understand that you have some doubts, but 
this is the current (1.5+ year old) IE5 implementation. I think you either 
mimick it, or start your own from scratch.

My argument for following the IE5 model is that it's already out there, and 
easier for IE developers to start using. If you have a better design, this 
should be discussed on the DOM list at w3 and incorporated into a future DOM 
spec. 
DOM defines an error event. Mozilla already sends (I think I implemented this)
error event when an image fails to load. We do not yet send error for failed
document load (this is problematic). This is why I was considering that error
might be more approppriate. There is also abort event (which we have not yet
implemented) which should be sent when the user stops the load.

However, I do not know if 404 or some such is in fact the kind of error that
would mean we'd need to fire error event.

Still, because we are trying to mimic IE here I would not want to change things
from the way IE does them unless there are pressing reasons to do so. So I agree
with  you here.
I am taking all XMLExtras bugs to make it easier to see what I am working on...
Assignee: vidur → heikki
Targeting for mozilla0.9.1
Target Milestone: --- → mozilla0.9.1
(Reporter)

Comment 8

18 years ago
Heikki, you've targeted this bug for a future release.

Do you have a plan what exactly to fix, and how?
No plan yet, I'll get to this after mozilla0.9.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 10

18 years ago
Doesn't look like this is getting fixed before the freeze tomorrow night.
Pushing out a milestone.  Please correct if I'm mistaken.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
We fire onload even for non-XML data, including 404 errors etc. There is also
responseText member now, as well as status and statusText that give you
information about the HTTP response. Marking as worksforme.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Updated

16 years ago
QA Contact: petersen → rakeshmishra
You need to log in before you can comment on or make changes to this bug.