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 comment:1
| resolution: | → worksforme |
|---|---|
| status: | new → closed |
Changed May 11, 2012 05:02PM UTC by 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 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 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 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 comment:6
| resolution: | worksforme |
|---|---|
| status: | closed → reopened |
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 comment:7
| owner: | → softwareelves@gmail.com |
|---|---|
| status: | reopened → pending |
Changed May 23, 2012 09:50PM UTC by 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 comment:9
| cc: | → jaubourg |
|---|---|
| owner: | softwareelves@gmail.com |
| status: | pending → new |
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 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 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 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 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 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 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 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?
Changed May 29, 2012 12:59AM UTC by comment:17
| component: | unfiled → ajax |
|---|---|
| milestone: | None → 1.8 |
| owner: | → gibson042 |
| priority: | undecided → low |
| status: | new → assigned |
Changed May 31, 2012 03:33PM UTC by comment:18
| resolution: | → fixed |
|---|---|
| status: | assigned → closed |
Fix #11743: Don't mask script errors in jQuery.ajax, closes gh-795.
Changeset: 742872984e000ff8e13b9a23e74852d1b549f161
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.