Skip to main content

Bug Tracker

Side navigation

#11743 closed bug (fixed)

Opened May 09, 2012 09:08PM UTC

Closed May 31, 2012 03:33PM UTC

jQuery silently ignores errors during script tag ajax request in $.appendTo()

Reported by: softwareelves@gmail.com Owned by: gibson042
Priority: low Milestone: 1.8
Component: ajax Version: 1.7.2
Keywords: Cc: jaubourg
Blocked by: Blocking:
Description

In the test case I'm including a javascript file via appendTo(). Allow errors that happen during the initial execution of the javascript are ignored because ``jQuery.ajax` in `jQuery.domManip`` is missing the error case to rethrow the error. For reference I was expecting it to act the same as if the script was loaded normally (uncomment to see).

http://pastebin.com/ZTHGF15k <~ test.html

http://pastebin.com/1vRfndNj <~ test.js

Attachments (0)
Change History (18)

Changed May 11, 2012 04:47PM UTC by dmethvin comment:1

resolution: → worksforme
status: newclosed

Looks like it works fine to me. http://jsfiddle.net/QYDZW/

I see an error on the console in IE9, Firefox, Safari and Chrome.

You mentioned "rethrow the error" but jQuery goes to great lengths to avoid any try/catch that might mask the browser details of script errors. If you have code that you think may throw an error as part of its normal behavior, you should wrap it in a try/catch yourself or use a window.onerror handler as a last resort.

Changed May 11, 2012 05:02PM UTC by anonymous comment:2

Your jsfiddle does work as intended for me (not sure why it's different). I've hosted my pastebin on dropbox for easy testing and it does still fail for me.

http://dl.dropbox.com/u/9535/jquery/test.html

Thanks

Changed May 22, 2012 02:06PM UTC by anonymous comment:3

Replying to [comment:1 dmethvin]:

Looks like it works fine to me. http://jsfiddle.net/QYDZW/ I see an error on the console in IE9, Firefox, Safari and Chrome. You mentioned "rethrow the error" but jQuery goes to great lengths to avoid any try/catch that might mask the browser details of script errors. If you have code that you think may throw an error as part of its normal behavior, you should wrap it in a try/catch yourself or use a window.onerror handler as a last resort.

I added a comment a little over a week ago showing that this bug still exists, but this ticket is still marked as closed. Should I reopen another ticket?

Changed May 23, 2012 06:20PM UTC by dmethvin comment:4

The difference between yours and mine is that I'm using jQuery (edge) which is the latest development version. Can you try with http://code.jquery.com/jquery-git.js and see if it is fixed there? Since the fiddle works I suspect it does.

Changed May 23, 2012 06:29PM UTC by anonymous comment:5

Replying to [comment:4 dmethvin]:

The difference between yours and mine is that I'm using jQuery (edge) which is the latest development version. Can you try with http://code.jquery.com/jquery-git.js and see if it is fixed there? Since the fiddle works I suspect it does.

I've updated my example (http://dl.dropbox.com/u/9535/jquery/test.html) with your edge version, and can confirm that the bug still exists in that version (I'm on mac chrome). I've included a screenshot of where the exception is getting eaten: http://i.imgur.com/0sebs.png.

I know your time as a jQuery is very valuable, thanks for taking the time to look at my issue again. Let me know if there is anything else you'd like me to do.

Changed May 23, 2012 09:21PM UTC by dmethvin comment:6

resolution: worksforme
status: closedreopened

Does this problem only occur on Chrome with the Mac? That would be very important to know.

Changed May 23, 2012 09:21PM UTC by dmethvin comment:7

owner: → softwareelves@gmail.com
status: reopenedpending

Changed May 23, 2012 09:50PM UTC by anonymous comment:8

Replying to [comment:6 dmethvin]:

Does this problem only occur on Chrome with the Mac? That would be very important to know.

It's also broken on Safari 5.1.7 Mac, FF3.6 Mac, FF12 Mac/PC, Chrome Win7, IE9 Win7 (which is all I've tested).

I've changed the example script slightly (http://dl.dropbox.com/u/9535/jquery/test.html) to display an alert after the appendTo call that shouldn't show (due to the error bubbling up), but in this case since the error is eaten, and the alert happens.

Changed May 23, 2012 11:58PM UTC by dmethvin comment:9

cc: → jaubourg
owner: softwareelves@gmail.com
status: pendingnew

OIC what is going on, I'm sure jaubourg would have caught it immediately. My test case grabbed the script from another domain so it used a script transport (script tag). Yours uses the same domain so it's XHR. And yes, when an XHR script is processed the error is caught.

I've included jaubourg for some thoughts on how we can make this a bit more consistent and/or better ways to accomplish this. You could always create a script tag and set its src property.

Changed May 24, 2012 12:09AM UTC by anonymous comment:10

Replying to [comment:9 dmethvin]:

I've included jaubourg for some thoughts on how we can make this a bit more consistent and/or better ways to accomplish this.

Many thanks, I look forward to this issue being resolved :-)

You could always create a script tag and set its src property.

In my case I have arbitrary HTML I'm injecting into the <head> tag using jQuery, so that isn't an option for me. I just simplified the test case so that it'd be easier to diagnose.

Changed May 24, 2012 01:09AM UTC by dmethvin comment:11

In my case I have arbitrary HTML I'm injecting into the <head> tag using jQuery

Do you mean you're expecting the script injection and execution to be synchronous? That won't happen, the request is async.

Unfortunately, the behavior of injected scripts isn't very well documented, but it's something we're trying to clarify for 1.8.

Changed May 24, 2012 01:20AM UTC by anonymous comment:12

Replying to [comment:11 dmethvin]:

> In my case I have arbitrary HTML I'm injecting into the <head> tag using jQuery Do you mean you're expecting the script injection and execution to be synchronous? That won't happen, the request is async. Unfortunately, the behavior of injected scripts isn't very well documented, but it's something we're trying to clarify for 1.8.

It appears to be synchronous according to my example (http://dl.dropbox.com/u/9535/jquery/test.html). The first alert ("hi") is from the script being included and the second ("this should not show") is in the <script> tag directly following the appendTo call.

I believe this synchronous behavior is from script fetching code in domManip:

jQuery.ajax({
	type: "GET",
	global: false,
	url: elem.src, //this is the url from <script> tag in appendTo call
	async: false,
	dataType: "script"
});

It seems that this ticket bug actually steams from this code incorrectly handling the errors (silently ignoring them).

Changed May 24, 2012 01:23AM UTC by dmethvin comment:13

Right, sync for XHR calls. I'll be quiet now and wait for professional help to arrive. :)

Changed May 24, 2012 01:34AM UTC by jaubourg comment:14

We don't have much choice here... adding an error handler and rethrowing will be of no use (obfuscation).

We need yet another option in ajax in order not to catch exceptions in converters so that the exception in the text to script converter "bubbles up" so to speak. We could not catch when async is false but we would break existing code.

Seems like a good addition while handling the sourceURL issue.

Changed May 24, 2012 01:48AM UTC by anonymous comment:15

Replying to [comment:14 jaubourg]:

We don't have much choice here... adding an error handler and rethrowing will be of no use (obfuscation). We need yet another option in ajax in order not to catch exceptions in converters so that the exception in the text to script converter "bubbles up" so to speak. We could not catch when async is false but we would break existing code. Seems like a good addition while handling the sourceURL issue.

I like that solution, how would it work in the case of async or would it only be allowed for sync requests?

Changed May 25, 2012 01:33PM UTC by gibson042 comment:16

The script converter is a weird case anyway; it's not so much ''converting'' as doing work that elsewhere would be set up in a prefilter or transport. So what if we just delineate its special behavior and catch true conversion errors closer to their source?

https://github.com/jquery/jquery/pull/795

Changed May 29, 2012 12:59AM UTC by mikesherov comment:17

component: unfiledajax
milestone: None1.8
owner: → gibson042
priority: undecidedlow
status: newassigned

Changed May 31, 2012 03:33PM UTC by Richard Gibson comment:18

resolution: → fixed
status: assignedclosed

Fix #11743: Don't mask script errors in jQuery.ajax, closes gh-795.

Changeset: 742872984e000ff8e13b9a23e74852d1b549f161