Random header image... Refresh for more!

Posts from — August 2010

Maybe they need to read their own best practices.

I got this error today.  It is a magnificent demonstration of several layers of FAIL.

August 19, 2010   No Comments

‘COMPATIBILITY’ is undefined

At work, I’m currently spending most of my time developing an internal webapp.  It’s the first significant work I’ve done in ASP.Net MVC and JavaScript, so it has been a great learning experiment.

Yesterday, I added a feature that involved JSON serialization to carry data on a round trip from the server to the client and back.  The feature is fairly straightforward:  The server writes one of its data objects to the page as a JSON string, which lets the JavaScript on the page interact with the object.  In response to a user action, the page will package up the object in JavaScript, turning it back into a JSON string, and pass it back to the server.  It feels like a bit of a hack, but hey, it works.

It works in some browsers, that is.  To get the object back into JSON format for the trip back to the server, I was using the method JSON.stringify(object).  The JSON object is apparently natively supported by IE8 and FF3.5 (And maybe Chrome, although I didn’t check), and since the target audience of this internal tool is already using one of those browsers, I don’t have to worry about compatibility.

Before checking into our CI system, which will deploy the code to a testing server, I run it locally.  Works fine in IE8.  Works fine in FF 3.6.  Everything’s happy.  SVN Commit and continue working.  If it’s working HERE, it’ll work THERE.

Or not…

About an hour after I check in this change, I go take a look at the testing server to verify a couple of unrelated changes.  I click on a link and I get a JavaScript error.

'JSON' is undefined

Um…  Excuse me?  I’m using IE8, which I know has a native JSON object.  It’s one of the things they brag about adding in IE8.  It’s there.  I know it’s there.  This worked just fine when I’m running it on my box, and it’s not like there’s some file I forgot to deploy that could cause a native JS object to disappear.  It has to be there…

So I try it in Firefox.  If something went wrong with the deployment or the testing machine, it would be broken in Firefox, too.  Of course, it works fine there.

I scour teh Intarwebz for help related to this error and find nothing useful.  Most of the advice is “Well, did you include ‘JSON2.js’?”, which is a file I’m not using and don’t need because JSON is a native object now.  It has to be there…

After wasting about an hour trying to find a solution, I performed my favourite problem solving manuever:  Throw away everything you know about the problem and start from scratch.  The branch of thought I was on before didn’t get anywhere, so it was time to explore a new direction.  In the initial search, I was looking for a solution to the “JSON is undefined” problem.  But maybe that’s not the problem.  Maybe that’s just the symptom of a different issue.  So now, I have to find what the problem really is.

  • Did the code not get checked in right?  The code is fine.  Nothing’s left in pending changes.
  • Did the JavaScript not get deployed correctly?  The deployment is fine.  All script files I have locally are on the testing server.
  • Have I ever come across anything like this before?  Yes.  IE’s security settings will treat intranet sites differently than Internet sites.

IE security settings…?  Well, that’s easy enough to check.

I go back to the page and change the server in its URL to be the fully qualified internal domain name for the server, not just the name of the server itself.  Hit the link…  Hey, it works!

So…  IE security settings, perhaps?  I consider simply ignoring the problem and telling everyone who uses this app to access the server with the full domain name, but quickly realize what a stupid solution that would be.

Why would this be a security setting, though?  Whenever I’ve run afoul of IE’s security model, it’s because I’ve been doing something that IE thinks could potentially be a risk to security.  It rarely is an actual risk (Unless trying to expand and collapse nodes in an XML file is risky in ways I cannot fathom), but there’s usually some semi-rational reason for blocking an action.  Killing the JSON object isn’t rational.  You can’t do anything with it that you couldn’t already do in JavaScript.  So why disable it?

And that’s when I noticed something.  On my localhost page, there was that little “broken page” button next to the address bar, but that button wasn’t there on the testing server.  WTF?  I didn’t force compatibility settings on the testing server, so why is that button missing?

I open up the Compatibility View Settings dialog and I find this inside:

“Display intranet sites in Compatibility View” is checked BY DEFAULT.

So, Compatibility View is what makes your browser act like IE 7 because so many websites out there were hacked together to work in IE6 and 7 because that’s whate everyone used.  As you may know, IE 6 and 7 were a bit wild when it came to rendering things, prefering the cowboy way of going it alone and doing what feels right, rather than, you know, attempting to follow standards.  When IE8 came along and fixed a lot of those issues, it meant that some poorly designed older pages looked like cat vomit.  So, Microsoft put in the Compatibility View button to make the pages render like they did in IE 7.

That’s all well and nice, except that A: They turned it on by default for intranet sites, and B: It’s not just rendering.  This is important, because I had no idea about this until yesterday.  Compatibility View also rolls back the JavaScript engine in IE to the previous version.  So…  No more JSON object!  Poof!  Gone!

DAMN YOU, IE6.  I’M NOT USING YOU AND I’M NOT EVEN DEVELOPING TO SUPPORT YOU AND YOU’RE STILL MAKING MY LIFE HELL.

So, what did I do?

<script src="Microsoft.Ajax.js" type="text/javascript"/>

That has its own JSON object in it and made my problem go away.  It’s a cop-out, true, but I don’t really care.  I’m trying to write an application that has absolutely nothing to do with stupid default compatibility settings and JavaScript engines and all that other nonsense.

August 18, 2010   4 Comments