History restored

I currently work on a Web2.0 project for a customer where we use AJAX extensively. We download all of the HTML code and JavaScript from index.html and every part of the application after that are implemented using DHTML and AJAX requests to the server.

To give the user the standard Web experience we are using a JavaScript library called Really Simply History. By using this library we can control that will happen if the user presses the back button in the browser.

The library worked great until IE7 started to appear. Suddenly we got strange "white-outs" of the pages. Then clicking a button or a link all HTML of the page was removed and only two buttons of the UI was left.

After some digging using Google I found a post in Spanish describing that went wrong and a fix. The problem seems to be that dhtmlHistory.js breaks the DOM in some way. I implemented the fix suggested by jorgemaestre and it worked, the whiteouts was removed.

But instead I got other problems. Pressing F5 for a page reload did not work as expected, after hitting F5 the site reloaded but I was taken back to the home page. This means the history function did not work. I did some debugging and discovered that for dhtmlHistory.js to work, the form field values needed to be preserved. I also found another post on the Internet about IE not saving the values of a form if it's created after the page has loaded.

The solution is to let the dhtmlHistory.js create it's form during normal page loading but as the last part of the page, after all other content. To implement the fix:

1) Open the dhtmlHistory.js and remove the last rows saying:

/** Initialize all of our objects now. */
window.historyStorage.init();
window.dhtmlHistory.create();

2) To your main index.html or whatever that's using dhtmlHistory.js add as the last part before </body>

</script>
/** Initialize all of our objects now. */
window.historyStorage.init();
window.dhtmlHistory.create();
</script>

IE7 does not Excel

The statistical module on one of our web applications has a function to download the data directly into Microsoft Excel. This function has been working like a charm since the application was deployed last year, but now we got problem reports from IE7 users that were unable to use the function.

I did a quick test and found no problem, a not so uncommon situation for anyone involved in software development. I thought about reporting the usual "It works in development" back to the customer when I figured I should do another test using the full test environment. I now got the reported failure; IE7 fails to download the file and a popup is shown instead. Aha! Its HTTPS that's causing this.

After some digging around I found the answer in the header() documentation on php.net. To get file downloads to work for IE7 you must add two more headers to the response:

header('Pragma: private');
header('Cache-control: private, must-revalidate');

This will tell IE7 to allow the encrypted file to be saved locally, a requirement to be able to open the file using Excel. I have not found any pointers about why the functionality was changed between IE6 and IE7.

I hope this saves an hour for you!

Hard disk slowfox

I've had some problems for the last weeks with the performance of my laptop and was looking around to buy a new one. But since it's a lot of comparing to do, to decide witch one to buy I was not able to find the perfect one so I started to investigate that was causing this. I ignored the usual helpfull comments about Windows slowing down over time, and questions about when I last reinstalled Windows.

I did the standard scans using Ad-Aware and did not find anything alarming. I removed all unneeded startup items from the registry and the start-up folders and stopped all services I could be without, but the computer still felt like an old 386. I was near or at 100% CPU utilisation without getting much work done, something must be broken.

I downloaded a performance measurement tool called PerformanceTest 6.1 to try to get a measurement of how slow my laptop was, and indeed it was slow. I got 1.2MB/s transfer rate to my hard disk. That is not much. I tried the program on my other machine and got 40MB/s. Now I was convinced something was terrible broken.

After a couple of hours of scanning for rootkits and examining all class filters for the hard disk device stack my brother suggested that I checked the DMA settings on the IDE channel. I said sure, let's check, because DMA is always active and I did not suspect it could be disabled. I was running my hard disk on PIO-mode! How could that be?

After another hour of investigations I had found the Microsoft Knowledge Base article KB817472 that explains the problem. If the driver receives errors from the hard disk, it tries to lower the transfer speed over the IDE channel. The real problem starts then using a laptop and you only hibernate the system since you are likely to get some errors then starting up again. My machine had lowered the transfer mode to the lowers PIO-mode where the CPU is used to output a byte at the time to the hard disk, at high cost of CPU cycles and very slow throughput.

The "fix" to this problem was simple, just delete the Primary IDE channel in device manager and reboot, and the system will plug and play the device back again with restored performance. Running PerformanceTest again gave me 25MB/s to the disk.

Microsoft has also added and option to disable this "feature" in the driver, and I think you can guess my setting...