Google Chrome and Auto Postbacks: What You WON'T See When Testing ASP.Net Apps

One common way developers transform a static web page into a dynamic web page (one that could contain different content based on varying circumstances) is by writing logic on the web server that essentially "generates" the HTML code that is needed.

Perhaps the ASP.Net code for my homepage is set to include a certain banner image if it's Friday, but a different banner for all other days of the week. When you visit my website, your browser is making a request to my web server. The web server checks the day, and only then sends the appropriate HTML code back to your browser. If today is Friday, you'll see my Friday banner at the top; otherwise you'll see another.


This is because the web server will send different HTML code based upon the circumstances. You can literally see the difference in this HTML code if you use the View Source feature in your browser on a Friday and then again on another day. It's different code being "translated" by your browser into content on the page.

Now, one of the most common ways in ASP.Net applications to dynamically update a page that’s already been requested (barring the use of AJAX) is to let the user make some choice that causes an auto postback. This means that you are already viewing a page in a browser, but something causes a new request to be made to the web server and it "re-generates" the HTML code for this same page, essentially updating it with new content.


For example, I might create a DropDownList that contains options for different headings to display on a page, then set the DropDownList's AutoPostBack property to true, and set its default event handler (SelectedIndexChanged) to display the heading chosen from the DropDownList. This configuration will cause an auto postback when you choose a different option from the drop down box on the page - meaning another request back to the web server to update this page. The web server will generate the appropriate new HTML code and send it back to your browser, where it will be reinterpreted and you'll see the new heading displayed.


Sample Code for an auto postback
Click on either image below for sample auto postback code. The first is the aspx page. The second is its aspx.cs C# code-behind file.

ASPX page code - auto postback example

ASPX.CS code-behind page - auto postback example



This is a very common technique. And for ASP.Net developers testing their application, it would be common not only to verify the browser screen has updated as expected after an auto postback, but also to use the View Source feature of the browser to see how the new code was generated.


Common Browser Handling of auto postback and ViewSource
Below is an example of the browser screen and View Source HTML code in Internet Explorer 8, before and after choosing an option from the dropdown list and causing an auto postback. Most browsers will display this behavior.

Common browser handling - Screen and ViewSource at initial page load:



Common browser handling - Screen and ViewSource after auto postback:



Notice how in the second image, after the user chose "Wacky Heading" from the dropdown list, two things happened? The heading changed in the browser screen, and the View Source window reflected the updated code that had been sent back from the server.


Google Chrome Handling of auto postback and ViewSource
But if you're using Google Chrome, the View Source won't show the updated code. Unlike all the other major browsers out there, Google Chrome does not actually update the HTML code that its View Source displays when you "post back" to the same page with updated code. It will still show the code generated from the first request to the web server (as in the "is-it-Friday-or-not" example above), but if there is an auto postback that results in different HTML code for the page, Google Chrome's View Source will only show the original HTML code, which is very misleading. The page you see in Chrome will update (say with the new "Wacky Heading" chosen from the drop down list) but if you view the source, Chrome will still be showing the originally requested HTML code file.


Google Chrome handling - Screen and ViewSource at initial page load:



Google Chrome handling - Screen and ViewSource after auto postback:



I'm personally still a big fan of the Chrome browser for many types of browsing, but ASP.Net programmers should beware of this bug when testing.

***2011/09/30 Update:

Note, since this post was created, Chrome appears to have "gone legit" in regard to its implementation of the View Source feature, and handles the process in the traditional way now, updating the source after postbacks. (Thanks to the screenshots from the original post, though, you can still see the behavior for a browser that handles postbacks in this way. Incidentally, you'll still see this type of behavior in any browser where an asynchronous JavaScript postback manipulates the DOM behind the scenes, and the View Source fails to be updated.)

- Eric Reid, Design Expert; CTT+, ACI (Adobe Certified Instructor), ACE (Adobe Certified Expert), i-Net+, IC3 LinkIn with Eric