Bug Tracker

Opened 8 years ago

Closed 5 years ago

#9883 closed feature (migrated)

Allow users to respond to other ajax event states.

Reported by: hungerandthirst@… Owned by: jaubourg
Priority: low Milestone: None
Component: ajax Version: git
Keywords: 1.9-discuss Cc:
Blocked by: Blocking:


The jQuery docs explicitly state that "No onreadystatechange mechanism is provided, however, since success, error, complete and statusCode cover all conceivable requirements."

Frankly I think that's limiting users unnecessarily. What if I want to respond to something when I get headers back? What if I want to know when I start receiving content back from the server?

An excellent example of this is using jQuery for bandwidth testing. Without a way to detect when I initially receive content back from the server (not just beforeSend), I will also include any delay spent waiting for the server to respond.

I've added support for the RECEIVE_HEADER and LOADING event as per the XMLHttpRequest specs in this pull request.

I would also like to see support for onreadystatechange as well since those are valuable states that we are only limiting ourselves and losing value by not tracking.

Change History (15)

comment:1 Changed 8 years ago by jaubourg

Component: unfiledajax
Milestone: None1.next
Owner: set to jaubourg
Priority: undecidedlow
Status: newassigned

First of all, onreadystatechange and xhr events support was removed from the original rewrite because:

  • size was beginning to be a real, blocking, issue
  • they're not used as much as one may think (there are use cases for them, but they do not represent a need widespread enough to justify the quite substantial bump in size, especially if you already have success, error and complete callbacks).

The jqXHR object doesn't strive to implement the whole xhr API. It's as complete an xhr-compatible wrapper as it makes sense relatively to the diversity of transports under the hood.

Your bandwidth detection example is clearly not a typical use-case for a web app (and that's putting it mildly). Beside, if you wanted to have full control over the xhr, you can still use jQuery.ajaxSettings.xhr() to create a native xhr (because, in the end, given the level of control you require, you don't need ajax to intervene on top of the native xhr -- by setting headers automagically without your knowledge for instance).

As to the patch itself, what I really don't like about it, is that you create specific options that only make sense for the xhr transport.

If you really want those right now and insist on using ajax for low-level control over the xhr, you can easily copy the code of https://github.com/jquery/jquery/blob/master/src/ajax/xhr.js, apply your patch and change line 52 into:

jQuery.ajaxTransport( "+*", function( s ) {

Drop the file as is in your application: it'll override the default xhr transport and you'll be able to do whatever you need to.

That being said, I know we need some progress notification system but, guess what? We'll have progress callbacks on Deferreds/Promises in 1.7 which would be a perfect fit for this kind of things :)

Given Deferreds' progress is transport agnostic, each transport will be able to provide its own progress notification protocol.

I leave this as opened for now, given that I'd love to see something to notify readyState changes using Deferreds' progress make it as soon as 1.7. But, since this wasn't brought when proposals for new features in 1.7 were in order, I doubt we'd see this before 1.8. On the other hand, the addition would be pretty neutral since progress callbacks didn't exist earlier (no code breakage since existing behaviour stays unchanged).


  • yes, we need some kind of a progress notification system for transports,
  • no, adding options specific to a given transport is not an acceptable approach,
  • let's use Deferreds' progress introduced in 1.7 for this so that all transports can notify their own "events".

I'll try and take this conversation forward in the next jQuery meeting.

comment:2 Changed 8 years ago by jaubourg

#9324 is a duplicate of this ticket.

comment:3 Changed 7 years ago by jaubourg

#10365 is a duplicate of this ticket.

comment:4 Changed 7 years ago by dmethvin

Type: enhancementfeature

Bulk change from enhancement to feature.

comment:5 Changed 7 years ago by gibson042

Keywords: 1.9-discuss added

comment:6 Changed 7 years ago by dmethvin

Do progress callbacks make this easy now?

comment:7 Changed 7 years ago by hungerandthirst@…

Don't know off the top. I will need to investigate and get back to you. Have not had a chance to look into the new callbacks yet.

comment:8 Changed 7 years ago by mikesherov

+0, I'm not informed enough to choose.

comment:9 Changed 6 years ago by gnarf

+1, I think we should at least look at using .notify to send something about this state change - Measure the size, and then decide

comment:10 Changed 6 years ago by mikesherov

Milestone: 1.next1.9

comment:11 Changed 6 years ago by jaubourg

FYI, preliminary study indicates adding a minimal implementation of a progress callback which the xhr transport would call at each readystate with the native xhr instance as sole parameter (so that it can be inspected and used) is in the vicinity of 30bytes min/gzipped. Any attempt to make it more secure (not expose the native xhr directly) or more useful (call the progress handlers with meaningful parameters) can only make it much bigger and is actually the disirable approach.

I'm quite torn here, because I know how useful it would be yet I feel like it will be too much weight at this point. Since I know the xhr transport will be extremely simplified for 2.x, I'd like to postpone this.

Version 0, edited 6 years ago by jaubourg (next)

comment:12 Changed 6 years ago by dmethvin

Milestone: 1.9None

I'm fine with moving this to a later date. We'll have plenty of other things to keep us busy in the next couple of months. :)

comment:13 in reply to:  12 Changed 5 years ago by anonymous

Replying to dmethvin: Just do it. If anything adding this support will introduce a lot of people to progress(), which I have always thought was such a clever part of $.Deferred.

comment:15 Changed 5 years ago by m_gol

Resolution: migrated
Status: assignedclosed
Note: See TracTickets for help on using tickets.