Changes in the ColdFusion.window.create Function Require a Modern Browser

error dialog box

I’m still working on upgrading some older CF8 applications to CF11. I came across an interesting problem, the exact cause of which I have not found, but I do have a solution of sorts.

When the particular application I’m working on now was written, the standard browser that would be accessing it was Internet Explorer 8. Over time, as we have upgraded our browsers, but not had time to make changes to the application to accommodate those new browsers, we had used the dreaded Compatibility View to keep the look and feel of the application unchanged.

Since we are now several versions out from CF8, it is understandable that some things intrinsic to ColdFusion have changed. Somehow, the way that the function ColdFusion.window.create renders JavaScript to create the pop-up window does not work with IE 8 or a newer browser emulating IE 8 (as we forced with the X-UA-Compatible HTTP header in IIS). After copying the website to the CF11 server, setting up everything in IIS, and navigating to the website, everything was great until I clicked on a link that executed a function (named “createCFWindow”, as in the dialog box below) that called the ColdFusion.window.create function.

This is the result:

error dialog box

After stepping through the code using Internet Explorer’s Developer Tools, I determined that the reason this “createCFWindow” function threw an exception was because the ColdFusion.window.create function was returning null rather than a new window.

When testing the website on Chrome – which this application was not designed to use – I discovered that the error did not occur, and decided to turn off Compatibility View. Sure enough, this error disappeared in IE 11 – though a host of other issues have now developed.

Now, I’m working to upgrade the application to be HTML5-compliant so it will work on IE 11 or Chrome.

Apparently, using CF UI tags became unfashionable quite some time ago, but that type of advice isn’t always heard or heeded until long after it’s announced.

Any future applications I build will use jQuery instead for this sort of thing.

Why is this Website Garbled?

DIYthemes site on Chrome

I use Thesis from DIYthemes for this blog, and have found it to be a very versatile system for customizing their themes. However, I saw that my HTML 5 validation was failing due in part to the use of deprecated attributes on a link tag. I decided to report the problem via the DIYthemes website, and found something very strange!

DIYthemes site on Chrome
This is how the DIYthemes website looked on Chrome.

At first I thought that perhaps I had ended up on their page in a foreign language, or maybe their site had been hacked. When I viewed the HTML source, the text appeared as it should. If I selected some of the text and copied and pasted it into mt text editor, the missing letters were there! Perhaps a JavaScript was running that hid certain letters?

When I opened the page in Internet Explorer 11, the page looked correct:

DIYthemes on IE11
How the website looked on IE 11.

At this point, I took a look at the Chrome DevTools window (you can use F12 to get there) to see if that would yield the information I needed. I saw a warning in the Console pane that might lead to an answer: “Failed to decode downloaded font: data:application/font-woff…”

DevTools window on DIYthemes page
The Chrome Developer Tools window can be very helpful!

By turning off the font-family tags in the DevTools window, I watched the website begin to look normal, albeit in a more generic font than what the site is supposed to use. So apparently, if a font is not properly decoded by the browser, it can omit characters and cause the site to look like the first picture above.

I’m not yet certain why my Chrome browser did not decode the font, where IE 11 did. This could be a bug on the DIYthemes site, or a problem with Chrome. In any case, this error can happen for a number of reasons, and some of those reasons can be found on Stack Overflow.