Ticket #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 | |
| Blocking: | Blocked by: |
Description
Change History
comment:2 Changed 2 years ago by jitter
- Owner set to todd@…
- Priority changed from undecided to blocker
- Status changed from new to pending
- Component changed from unfiled to event
- Milestone changed from 1.next to 1.5.1
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.
comment:3 Changed 2 years ago by todd@…
- Status changed from pending to new
Yep, I'll dig into this tomorrow morning and provide a good example when I have access to IE7 again. Thanks!
comment:4 Changed 2 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 2 years ago by jitter
- Cc jaubourg added
- Status changed from new to pending
- Component changed from event to core
comment:6 Changed 2 years ago by jaubourg
- Owner changed from todd@… to jaubourg
- Status changed from pending to assigned
Damn, totally forgot I had to fix this.
comment:7 Changed 2 years ago by jaubourg
- Status changed from assigned to closed
- Resolution set to fixed
Fixes #8353. Adds a catch block in resolveWith so that the finally block gets executed in IE7 and IE6.
Changeset: cacea6f7e778d42cda56066a6b1da8fb163410cc
comment:8 Changed 2 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 2 years ago by jaubourg
- Status changed from closed to reopened
- Resolution fixed deleted
- Milestone changed from 1.5.1 to 1.next
comment:10 Changed 2 years ago by jaubourg
- Status changed from reopened to closed
- Resolution set to wontfix
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:12 Changed 2 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 2 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 = { optA:1, optB:2, optC:3, } ...
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
Please follow the bug reporting guidlines and use jsFiddle when providing test cases and demonstrations instead of pasting the code in the ticket.


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