Bug Tracker

Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#8353 closed bug (wontfix)

Bug in resolveWith in 1.5 on IE7

Reported by: todd@… Owned by: jaubourg
Priority: low Milestone: 1.next
Component: core Version: 1.5
Keywords: Cc: jaubourg
Blocked by: Blocking:


I've tracked down an issue in the resolveWith method in 1.5 core.

Because IE sucks I can't determine a stack trace, but the error I get is as follows:


If I add an empty catch within the resolveWith method the issue goes away (it just has try/finally).

Please contact me if you need any further info.

Change History (13)

comment:1 Changed 13 years ago by anonymous

It seems this is a known issue in IE that was fixed in IE 8 --> http://webbugtrack.blogspot.com/2007/11/bug-184-catch-to-try-catch-finally-in.html

comment:2 Changed 13 years ago by jitter

Component: unfiledevent
Milestone: 1.next1.5.1
Owner: set to todd@…
Priority: undecidedblocker
Status: newpending

Thanks for taking the time to contribute to the jQuery project by writing a bug report.

The link to your image seems broken.

Also please submit a reduced test case, which reproduces the issue you are experiencing, on http://jsfiddle.net. So that we can investigate this issue further. Also make sure to read the link given below, in order to provide a most useful bug report.

How to report bugs

comment:3 Changed 13 years ago by todd@…

Status: pendingnew

Yep, I'll dig into this tomorrow morning and provide a good example when I have access to IE7 again. Thanks!

comment:4 Changed 13 years ago by todd@…

Here's the image link: http://twitpic.com/42n4ea

It's a really odd error message because my code had nothing to do with setting focus to an element.

comment:5 Changed 13 years ago by jitter

Cc: jaubourg added
Component: eventcore
Status: newpending

comment:6 Changed 13 years ago by jaubourg

Owner: changed from todd@… to jaubourg
Status: pendingassigned

Damn, totally forgot I had to fix this.

comment:7 Changed 13 years ago by jaubourg

Resolution: fixed
Status: assignedclosed

Fixes #8353. Adds a catch block in resolveWith so that the finally block gets executed in IE7 and IE6.

Changeset: cacea6f7e778d42cda56066a6b1da8fb163410cc

comment:8 Changed 13 years ago by jaubourg

Revert "Fixes #8353. Adds a catch block in resolveWith so that the finally block gets executed in IE7 and IE6."

This reverts commit cacea6f7e778d42cda56066a6b1da8fb163410cc.

Changeset: 5d9db486c774c10293d0813c89dfdbd973120030

comment:9 Changed 13 years ago by jaubourg

Milestone: 1.5.11.next
Resolution: fixed
Status: closedreopened

comment:10 Changed 13 years ago by jaubourg

Resolution: wontfix
Status: reopenedclosed

After discussion, it seems unreasonable to make debugging in every browser a nightmare (using a rethrow will screw traceability). Since this only occurs in IE7, then IE7 will be the only browser that will have deferreds dead-locked in case of an exception.

Getting back to your specific case, an exception is thrown from the callback and, thus, has to be notified: there clearly is an issue in your code, not in resolveWith. Adding an empty catch block will not solve your problem, it will only hide it.

comment:11 Changed 13 years ago by jaubourg

Priority: blockerlow

comment:12 Changed 13 years ago by todd@…

I'll work on a proper use case tomorrow. I'm pretty convinced that it was jQueryUI code that was throwing the exception (so maybe the bug belongs elsewhere).

comment:13 Changed 12 years ago by Ted

just an odd fyi, I ran into the same problem--but the error was in my code, and not so obvious. In a jQuery plugin I was writing, I had an object with a missing last element, for example:

 (function( $ ){
    var options = {

that last comma after the last entry didn't kick up any warnings in the IDE, and kicked out the odd error (and epic fail) that the 'finally' method wasn't supported only in IE7.

So if you run into this problem, double check any objects you've instantiated for an extra comma.

HTH, -Ted

Note: See TracTickets for help on using tickets.