Skip to main content

Bug Tracker

Side navigation

#7763 closed bug (plugin)

Opened December 13, 2010 02:22PM UTC

Closed April 17, 2011 09:29PM UTC

Script transport doesn't handle errors

Reported by: iliakan Owned by: jaubourg
Priority: low Milestone: 1.6
Component: ajax Version: 1.4.4
Keywords: Cc: jaubourg
Blocked by: Blocking:
Description

Script transport handles successful onload only. I could add a partial error-handling to it which works except few IE subversions and Opera.

Is that needed?

Attachments (0)
Change History (11)

Changed December 13, 2010 04:20PM UTC by rwaldron comment:1

component: unfiledajax
owner: → iliakan
priority: undecidedlow
status: newpending

Thanks for taking the time to contribute to the jQuery project! Please provide a reduced jsFiddle test case to help us assess your ticket!

Additionally, test against the latest jQuery release and the jQuery 0 GIT version to ensure the issue still exists. Be Excellent to eachother!

I'm suspicious this may be related to #6060

Changed December 13, 2010 06:42PM UTC by jitter comment:2

_comment0: Is this what you talked about with [algo] on IRC. What was the outcome?1292265759306667
cc: → jaubourg

jaubourg is this what you talked about with [algo] on IRC? What was the outcome?

Changed December 13, 2010 11:38PM UTC by jaubourg comment:3

Ilia & I are currently investigating the issue which has more to do with jsonp error handling and being able to do that cross-browser with no sniffing involved.

Even if we manage to pull it off, the "hack" for IE (which consists in executing the code as a function -- don't ask) would fail with scripts that declare global variables without attaching them to the window object.

Yet we're investigating a solution for jsonp at least.

Changed December 14, 2010 07:50PM UTC by iliakan comment:4

_comment0: The summary as I see it: \ \ * Browser sniffing is replaced by feature sniffing \ * JSONP gets complete error handling \ * Script gets partial error handling \ \ I believe, partial error handling is better than no handling at all, just because errors do occur. A developer needs to track them down *somehow*. Partial error handling + timeout is better than "consistent" not handling here.1292356435099535
_comment1: The summary as I see it: \ \ * Browser sniffing is going to be replaced by feature sniffing \ * JSONP gets complete error handling \ * Script gets partial error handling \ \ As to the last point - I strongly believe that partial error handling is better than no handling at all, just because errors do occur. A developer needs to track them down ''somehow''. So partial error handling is better than "consistent" not handling. \ \ The usage pattern for catching errors will be "onerror" + timeout. Much better than just timeout.1292356606332104
_comment2: The summary as I see it: \ \ * Browser sniffing is going to be replaced by feature sniffing \ * JSONP gets complete error handling \ * Script gets partial error handling \ \ As to the last point - I strongly believe that partial error handling is better than no handling at all, just because errors do occur. A developer needs to track them down ''somehow''. So partial error handling is better than "consistent" not handling. \ \ The usage pattern for catching errors will be "onerror" + timeout. Much better than just timeout. \ \ Please comment if you see any problem with the points above..1292356629970202
status: pendingnew

The summary as I see it:

  • Browser sniffing is going to be replaced by feature sniffing
  • JSONP gets complete error handling
  • Script gets partial error handling

As to the last point - I strongly believe that partial error handling is better than no handling at all, just because errors do occur. A developer needs to track them down ''somehow''. So partial error handling is better than "consistent" not handling.

The usage pattern for catching errors will be "onerror" + timeout. Much better than just timeout.

Please comment if you see any potential problem with the points above..

Changed December 14, 2010 11:02PM UTC by jitter comment:5

Replying to [comment:4 iliakan]:

The usage pattern for catching errors will be "onerror" + timeout. Much better than just timeout.\\\\ Please comment if you see any potential problem with the points above..

Reads as: IE/Opera users with a slow connection or slow servers are doomed. That prospective doesn't look good to me.

Changed December 17, 2010 12:28AM UTC by dmethvin comment:6

Yeah it's not ideal. But...if we can prescribe which situations can be reliably handled in IE/Opera then developers have a way to create reliable pages.

Changed December 18, 2010 08:52AM UTC by iliakan comment:7

jitter: it's up to developer to set timeout or not.

The point is, again, the error is to be handled.

There is nothing worse than just letting a user stare into "loading" screen for an hour.

At this moment, programmers have no way to catch errors besides timeout. We should give it to them. So they don't use timeout all the time.

Isn't that clear?

Changed January 04, 2011 07:22PM UTC by snover comment:8

If this is a verified issue could someone please set this to open/assigned and give it a milestone?

Changed January 09, 2011 02:06AM UTC by snover comment:9

status: newpending

Changed January 11, 2011 07:20PM UTC by jaubourg comment:10

owner: iliakanjaubourg
status: pendingassigned

I'll take ownership seeing as Ilia somehow disapeared. Not sure the best solution isn't simply a jsonp plugin seeing as detecting errors is only possible for jsonp and would mean duplicated script tag injection code (one for jsonp, another for script).

Changed April 17, 2011 09:29PM UTC by john comment:11

resolution: → plugin
status: assignedclosed

Sounds like this is going to end up as a plugin? Correct me if I'm wrong, Julian.