#8353 closed bug (wontfix)
Bug in resolveWith in 1.5 on IE7
Reported by: | Owned by: | jaubourg | |
---|---|---|---|
Priority: | low | Milestone: | 1.next |
Component: | core | Version: | 1.5 |
Keywords: | Cc: | jaubourg | |
Blocked by: | Blocking: |
Description
Change History (13)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Component: | unfiled → event |
---|---|
Milestone: | 1.next → 1.5.1 |
Owner: | set to todd@… |
Priority: | undecided → blocker |
Status: | new → pending |
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 13 years ago by
Status: | pending → 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 13 years ago by
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
Cc: | jaubourg added |
---|---|
Component: | event → core |
Status: | new → pending |
comment:6 Changed 13 years ago by
Owner: | changed from todd@… to jaubourg |
---|---|
Status: | pending → assigned |
Damn, totally forgot I had to fix this.
comment:7 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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
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
Milestone: | 1.5.1 → 1.next |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
comment:10 Changed 13 years ago by
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
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
Priority: | blocker → low |
---|
comment:12 Changed 13 years ago by
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
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
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