failure in ie7 when document.domain is set

[GoogleCodeExporter]

What steps will reproduce the problem?
IN IE7:
document.domain = "example.com"
$.jsonp({url: "http://data.example.com/foo.json", success:
function(){alert('yay!')} });

What is the expected output? What do you see instead?
expected alert with "yay!", instead got the error message "Access is Denied."

What version of the product are you using? On what operating system?
jquery.jsonp.1.0.4.min.js, testing with IE7 on Windows XP Professional

Please provide any additional information below.
Tracked the issue down to line 114 (in the non-minimized version):
D = W.document;

IE isn't allowing access to the document, I can only assume because it
thinks the iframe has a different domain.

Original issue reported on code.google.com by mdavis.time@gmail.com on 11 Jun 2009 at 6:03

[GoogleCodeExporter]

Another test (still in IE7 on Win XP Pro):

success = function() { alert('yay!'); };
error = function() { alert('boo!'); };
url = "http://data.example.com/foo.json";

go = function() {
  $.jsonp({url: url, success: success, error: error});
};

// IN FIREBUG-LITE:
go(); // => success!
document.domain; // => "www.example.com"
go(); // => success!
document.domain = "www.example.com" // NOTE: not changing the value!
go(); // => FAIL: "Access is Denied."

Original comment by mdavis.time@gmail.com on 11 Jun 2009 at 8:11

[GoogleCodeExporter]

Yeah, it seems it's a known issue on IE with iframes. The solution is 
apparentely to 
try to get the document until IE accepts (which involves some plumbery with 
setTimeout 
trickery). I'm curious though as why you would need document.domain. I'm not 
under the 
impression a lot of people actually use this dreadful feature. Am I wrong?

Original comment by aubourg.julian on 6 Jul 2009 at 3:04

• Changed state: Accepted
• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

Again... forgot to take ownership...

Original comment by aubourg.julian on 6 Jul 2009 at 3:32

[GoogleCodeExporter]

I'm guessing that you're not wrong and that a lot of people are able to avoid 
dealing
with document.domain and its issues.  We're being forced to deal with it because
we're running data services which require that we POST to a sub-domain via
javascript.  I was using this extension to detect 404s; but, with the issue in 
IE,
I've had to rip it out and find another way.

Original comment by mdavis.time@gmail.com on 7 Jul 2009 at 9:28

[GoogleCodeExporter]

I'm sorry to hear that. I know how painful it is to have dangling callbacks... 
that's 
the very reason I made the plugin in the first place. Now it may be in low 
priority 
but, hell, it's not like I have a million things to fix.

Anyway, I know how projects go, you must be far far away by now :)

Good luck on your endeavors.

Original comment by aubourg.julian on 7 Jul 2009 at 9:54

[GoogleCodeExporter]

All right. I made some trial & errors and fact is dealing with this involves a 
lot of 
trickery which is, imo, far too extensive and performance impacting.

When a project comes to the use of document.domain, it means subdomains and 
quite a 
degree of control server-side... which would point to proxy usage rather than 
jsonp. 
This will fall in the known limitations area.

Original comment by aubourg.julian on 10 Jul 2009 at 1:54

• Changed state: WontFix

[GoogleCodeExporter]

Version 2.0pre uses a new approach and doesn't suffer from the same limitation 
:)

Original comment by aubourg.julian on 11 May 2010 at 5:16

• Changed state: Fixed