Bug Tracker

Ticket #7763 (closed bug: plugin)

Opened 4 years ago

Last modified 3 years ago

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
Blocking: Blocked by:

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?

Change History

comment:1 Changed 4 years ago by rwaldron

  • Owner set to iliakan
  • Priority changed from undecided to low
  • Status changed from new to pending
  • Component changed from unfiled to ajax

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

comment:2 Changed 4 years ago by jitter

  • Cc jaubourg added

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

Last edited 4 years ago by jitter (previous) (diff)

comment:3 Changed 4 years ago by jaubourg

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.

comment:4 follow-up: ↓ 5 Changed 4 years ago by iliakan

  • Status changed from pending to new

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..

Version 2, edited 4 years ago by iliakan (previous) (next) (diff)

comment:5 in reply to: ↑ 4 Changed 4 years ago by jitter

Replying to 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.

comment:6 Changed 4 years ago by dmethvin

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.

comment:7 Changed 4 years ago by iliakan

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?

comment:8 Changed 4 years ago by snover

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

comment:9 Changed 4 years ago by snover

  • Status changed from new to pending

comment:10 Changed 4 years ago by jaubourg

  • Owner changed from iliakan to jaubourg
  • Status changed from pending to assigned

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).

comment:11 Changed 3 years ago by john

  • Status changed from assigned to closed
  • Resolution set to plugin

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

Note: See TracTickets for help on using tickets.