Every few years I run into an issue with JavaScript-based rich text editors and spellcheckers when they spawn pop-ups. The pop-ups open but don’t function.
If I open my Firebug console in the pop-up, I see something like:
Permission denied for <http://assets2.mysitedomain.com> (document.domain has not been set) to get property Window.tinymce from <http://www.mysitedomain.com> (document.domain has not been set).
Chrome’s console, shows a similar error:
Unsafe JavaScript attempt to access frame with URL http://www.mysitedomain.com/mypage from frame with URL http://assets2.mysitedomain.com/javascripts/lib/tiny_mce/themes/advanced/source_editor.htm. Domains, protocols and ports must match.
In this case, TinyMCE‘s HTML plugin is running-up against JavaScript’s same origin policy because I’m serving assets (and therefore TinyMCE pop-ups) from a different fully-qualified domain name than the page TinyMCE is being embedded in. When not explicitly set, my site’s pages will default to something like www.mysitedomain.com and TinyMCE’s document domain will default to assets2.mysitedomain.com.
The simple fix is to bump up the document domain on my site’s pages to just mysitedomain.com. I do this in my global JavaScript file. I do the same thing to TinyMCE’s tiny_mce_popup.js file.
document.domain = 'mysitedomain.com';
(You might also know that cookies need a similar bump when trying to read and write to them across subdomains.)
Although this works, there is a problem for those developing locally: there’s a good chance they’re not developing at mysitedomain.com but something like localhost. A page at localhost certainly isn’t allowed to claim its document domain is mysitedomain.com.
To handle both cases, we can instead set the document domain smartly, by putting this in both our global JavaScript file and in tiny_mce_popup.js:
document.domain = /(\w+)(.\w+)?$/.exec(location.hostname)[0];
Ian Lotinsky 
yesss thank you so much for this!
You’re most welcome! I’m glad this article was of some help.
This helps me too and works for 127.0.0.1.
document.domain = document.domain;
looks like an awfully clever workaround, and i hope to try it soon. does this effectively do away with the same origin policy?
Thanks. It doesn’t do-away with the same origin policy. The problem is that pages at foo.bar.com and bar.com aren’t of the same origin. This trick just bumps foo.bar.com down to bar.com so that both pages are now of the same origin: bar.com. Does that make sense?
Hi,
Is this still a valid solution. Since I am not able to do this. I have a dot net page which calls a java widget(which does the type ahead search like google) in an iframe. My Dot net page as well the java widget which I am calling are on two different sub domains under the parent domain. And I tried settign both the domain to the same but still getting an access denied. I am trying this on IE7. Any help?
Thanks
Prashant
Yes, this solution is still valid for pages that have JavaScript assets served from a different subdomain. I believe you are running into a different issue entirely: iframe security. I suggest posting your set up and question on StackOverflow to get some help from the broader community.
This posting helps and works for me.
Thanks,
Muthu