As some of you are aware, most of the time at my job is spent writing applications using Microsoft’s .NET development platform. While not hipster and probably frowned upon in the “cool kids” section at dev conferences, it’s pretty robust and (for the most part) works quite well. At the very least, it’s served our business quite well for the past 6 years.
[To my normal readers (especially Jayme), please feel free to stop here if you’d like. I will not be offended if you do, as what follows is code geekery that only a few of you will care about. But, hey, if you’re still interested, I would love for you to continue!]
Anyhoo, recently we had a couple of calls from the field stating that their inventory counts hadn’t gone through at all when trying to input them at the end of the month. Curiously, the users that were calling were ones who had received computers fairly recently and happened to be running IE9, while most of the company is still on IE8. After troubleshooting and verifying this issue with my own machine (and a couple of others), I determined it was an issue specifically with IE9.
Knowing that, I fired up Visual Studio and loaded the running app code on my dev machine and tried it out. IE8…works as expected. IE9…fail. I then went to the code to see exactly what it was doing (or not doing) that may cause this. To describe the process quickly, the page asks the user to build a list of products (with their corresponding counts) and then submit them all at once with one button click. Mostly, this gives the user a chance to compare their written list with the one they just built to make sure they input everything correctly. This has worked great for roughly 2.5 years or so.
To hold this list of products the user is inputting, I set a session variable called “PhysicalInventoryCount” to the DataTable object they are building as they go along. (ASP.NET handles session variables through an object simply called Session.) When they are ready to submit their inventory (assuming all products have been entered), they hit a button that is located within the FooterTemplate of a Repeater control. Pretty standard stuff. The only difference here is that the submit button has a custom onclick event that I set during the ItemDataBound event from the Repeater control. That onclick event is as follows:
btnSubmit.Attributes.Remove("onclick");
string strConfirmationMessage = "Are you sure?";
btnSubmit.Attributes.Add("onclick", "if(confirm('" + strConfirmationMessage + "') == true) {this.disabled = true; " + this.Page.ClientScript.GetPostBackEventReference(btnSubmit, null) + ";}else {return false;}");
This causes a browser-genrated dialog window to pop up and ask the user (in our case) “Are you sure?”. If the user selects the true case (“OK” or “Yes” from the dialog, depending on the browser), the following code runs:
this.disabled = true; this.Page.ClientScript.GetPostBackEventReference(btnSubmit, null);
For those new to ASP.NET, the
this.Page.ClientScript.GetPostBackEventReferencemethod simply makes the javascript call to the postback mechanism that normally fires when the form is submitted. What all of that means is that when the user clicks the button and answers yes to the question of “Are you sure?”, the following code should execute:
DataTable tblProducts = (DataTable)Session["PhysicalInventoryCount"];
System.Diagnostics.Debug.WriteLine("Products in table: " + tblProducts.Rows.Count.ToString());
if (tblProducts.Rows.Count > 0) {
this.lblStatus.Text = "GOOD";
}
else {
this.lblStatus.Text = "BAD";
}
For brevity and readability, I’ve shortened and simplified the code. What should happen is that the Label control with id of lblStatus should be populated with the string “GOOD”. And that does, in fact, happen with IE8 and every other browser. Not so much with IE9. With IE9, I get the “BAD” result.
Doing a little more digging into the code, I noticed that this interaction on the page was wrapped in an UpdatePanel control. Again, for those not acquainted with ASP.NET, the UpdatePanel control gives the interaction a more AJAX-y feel. Simply put, it prevents the page from having to refresh completely, or flicker, when you interact with the page contents. Think Facebook status updates.
Alright, let’s turn that off and see what happens. Boom. It worked as expected. Why?
Honestly, I don’t know the technical reason as to why. Doing some research on Google, I learned that Microsoft completely changed their Javascript engine with IE9, in an effort to make it faster and more up-to-date with the other browser makers. That’s great news to the average consumer. Scary as hell to developers like me. Because now they’re introducing changes that may (or may not) break things. Uncertainty kills.
So, my overall solution to this issue was to simply remove the UpdatePanel control and let the page refresh itself normally. This is fine for this particular page because it is one of our lightest. But, what if it wasn’t? What if it was your Facebook timeline, for instance? There’s ton of information on that page. Every time you want to update something, everything has to refresh? Um, no.
IE9 broke my shit!
