Usually, when coding a web page that's targeting users of IE and Firefox, the browser that's going to cause the lesser amount of problems is Firefox. So I was genuinely surprised when I came across a bug reported for Firefox only that came down to what I consider the browser misbehaving.
The requirements for our app included a series of dropdown boxes, where the selection a user makes in one dropdown drives the choices that appear in the next one (what's commonly referred to as a "cascading dropdown"). For a nicer user experience, this is typically done with AJAX, so that the request/response that generates the second dropdown upon selection of the first doesn't require an entire page refresh. ASP.Net makes this really easy with the UpdatePanel
control. Controls inside of an UpdatePanel
can be refreshed without reloading the entire page. It's not as lean as a pure AJAX call could be, since the server reprocesses the whole page, but the coding time is greatly reduced.
Our environment includes a standard master page that includes a ScriptManager
component (required for using UpdatePanel
s) and the following script:
<script language="javascript" type="text/javascript">
function onEndRequest(sender, args) {
ajaxPostBackButton.disabled = false;
var error = args.get_error();
if (error != null) {
window.location = "../errorPage.aspx";
}
var updateProgressPanel = $get("<%=this.UpdateProgressPanel.ClientID %>");
updateProgressPanel.className = "HideObject";
}
function onBeginRequest(sender, args) {
var ajaxPostBackButtonId = args.get_postBackElement().id;
ajaxPostBackButton = document.getElementById(ajaxPostBackButtonId);
ajaxPostBackButton.disabled = true;
var updateProgressPanel = $get("<%=this.UpdateProgressPanel.ClientID %>");
updateProgressPanel.className = "DisplayProgressLayer";
}
var ajaxPostBackButton;
Sys.WebForms.PageRequestManager.getInstance().add_beginRequest(onBeginRequest);
Sys.WebForms.PageRequestManager.getInstance().add_endRequest(onEndRequest);
</script>
The script, in essence, binds a couple of functions to the AJAX start and stop methods that do this:
- On start:
- Disable the control used to trigger the AJAX call (this helps guard against double-posting)
- Show a div that contains a "loading" animated gif to let the user know something's happening
- On end:
- Enable the control used to trigger the AJAX call
- Check for an error, and if found, redirect the browser to the standard error page
- Hide the div with the "loading" gif
Now, if the user makes a selection in the first dropdown, everything runs normally, and the second dropdown appears. If the user then presses F5 to refresh their browser, the browser reloads the page from its initial load state, i.e., with the first dropdown with the initial "Please select…" option selected, and no second dropdown.
At least, that's the way it works in IE. In Firefox, what I was seeing was, the first dropdown was getting selected to the option I had selected before I hit refresh, it was disabled, and there was no second dropdown.
Finding out why was no easy task. With the help of Firebug, I was able to show that, on refresh, neither the onBeginRequest
nor the onEndRequest
methods were being called, and those were the only places the dropdown's enabled state was being tinkered with. I could only conclude that Firefox itself was setting this state. But why, and how do I stop it?
A couple hours of internet searching on why a dropdown in an UpdatePanel
would be disabled failed to yield any useful information. I did find one user complaining about Firefox repopulating form values with prior input on refresh; unfortunately, that user's request for how to get around it was met with a snarky response about how it was a useful feature of Firefox and how the user was mentally deficient for not appreciating it. Sorry, but when you're coding a web application that is trying to control the content of form values and states and react to changes, and the browser breaks all rules and changes those states without raising any events to react to, I'll have to go with the feature being deficient and buggy.
Coming at the problem the next day with a fresh set of search terms, I came across this blog post: Firefox refresh viewstate updatepanel bug hell!!! The post describes a more serious error that can occur with Firefox's mucking about with a form after refresh that got updated with AJAX. The solution, renaming the form's ID on every refresh, seemed a little more of a brute-force hack than I wanted, and he mentions it doesn't work well in a master page scenario anyway (which we're in).
The comments on that post, however, point to an article on developer.mozilla.org that describes the feature in more detail and, more importantly, how to turn it off. By adding the nonstandard attribute autocomplete="off"
to the page's <FORM>
tag, it suppresses this bothersome behavior and lets the page work as expected.
We're now determining if this action is something that should be done site-wide (add it in the master page's markup), as it could be an uncaught bug on other pages; or if it's something that should be done on a page-by-page basis, by adding this.Page.Form.Attributes["autocomplete"] = "off";
to the prerender event of any affected page.