Friday, April 16, 2010

Crossdomain is not Crossbrowser ...

While Safari and Chrome are pretty modern browsers that don't usually disappoint, in web programming, you can never be sure. I am talking about the way cross-domains is implemented.

In javascript, as a security feature, access to some objects is restricted based on document origin. If that was cryptic, here is a concrete example. A frame in a page can't read the location of the parent using property , if the frame came from a different webserver than the parent.

That is, if you do something like this inside the iframe

location =

you would get an exception in Firefox, and IE (at least the more recent versions)

Error: uncaught exception: Permission denied to get property

I guess that is what the RFC may have prescribed. However, the behavior in Chrome and Safari is different. (And chrome and safari both are based on Webkit, so its essentially webkit). They will not throw an exception, but instead merely return undefined.

Now this initially seems counter intuitive, but to think of it, I believe there is a reason why webkit behaves so. Let's say you have the following code

location =
// do something

In firefox, the code that follows will never execute, because an exception was thrown when we accessed This will not be intuitive to a lame javascript programmer. Or so thought the makers of Webkit, who decided that it is smarter not to throw an exception and just set location to undefined, so that doSomething gets called. Which means any 'not so lame programmer' who writes this

try {
location =
} catch {

will find that their code wouldn't work as expected on Safari and Chrome.

Which is why it is important to adhere to the specs, in letter and spirit.

No comments: