Posts from — August 2010
August 19, 2010 No Comments
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.
'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.
- 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.
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.
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?
August 18, 2010 4 Comments