Friday, March 02, 2007
Cover your buttons
Microsoft users sometimes wait years for mistakes to be repaired. Such appears to be our fate with the "Hurry Up and Crash" bug that has plagued ASP.NET 2.0 since its release. A report of the bug appeared on Microsoft's Connect site three months after product release, followed by repeated comments from developers urging Microsoft to fix the problem.
The "Hurry Up and Crash" bug appears when a user of an ASP.NET 2.0 application clicks on a button or exercises another control "too soon." That crashes the application. If the user is lucky, a diagnostic appears saying, "Validation of viewstate MAC failed." Only users in Microsoft's UI development group are likely to understand. The cause of the problem is that ASP.NET 2.0 event validation may fail if a postback occurs before a page has been fully interpreted by Internet Explorer or by another browser that provides early activation of controls.
Developers were alarmed. This is a Class 1 bug threatening most ASP.NET 2.0 applications. It is unpredictable and also fatal. Forum pages buzzed with unhappiness, but Microsoft took a couple of months to say "Many thanks for your feedback. We are investigfating [sic]." The "Hurry Up and Crash" bug is so gross it seems hard to believe Microsoft testers missed it before product release. But maybe they didn't.
Finally, about a year after a report of the bug appeared on the Connect site, Microsoft offered its lordly opinion, a gem of sorts: "...we are being very strict about the number and scope of bugs that are fixed...we are not able to address it....Before starting work on the next full release of the .NET Framework, we will review the Connect data to help us identify and address the top customer reported issues." So there we have it. A bug that can crash almost any application -- maybe it will be fixed some time in 2009 or 2010. Maybe not; this bug might never make the cut.
The answer, of course, is to cover your buttons. Since the release of ASP.NET 2.0 a new Web site paradigm has begun to appear: the page with a curtain of decoration that vanishes to reveal content. A less drastic approach is to specify every potentially troublesome control with visibility hidden. Then at the end of page markup add JavaScript to make them visible. By the time a browser reaches that point it will (probably) have interpreted Microsoft's critical elements and can do postbacks correctly.
The "Hurry Up and Crash" bug appears when a user of an ASP.NET 2.0 application clicks on a button or exercises another control "too soon." That crashes the application. If the user is lucky, a diagnostic appears saying, "Validation of viewstate MAC failed." Only users in Microsoft's UI development group are likely to understand. The cause of the problem is that ASP.NET 2.0 event validation may fail if a postback occurs before a page has been fully interpreted by Internet Explorer or by another browser that provides early activation of controls.
Developers were alarmed. This is a Class 1 bug threatening most ASP.NET 2.0 applications. It is unpredictable and also fatal. Forum pages buzzed with unhappiness, but Microsoft took a couple of months to say "Many thanks for your feedback. We are investigfating [sic]." The "Hurry Up and Crash" bug is so gross it seems hard to believe Microsoft testers missed it before product release. But maybe they didn't.
Finally, about a year after a report of the bug appeared on the Connect site, Microsoft offered its lordly opinion, a gem of sorts: "...we are being very strict about the number and scope of bugs that are fixed...we are not able to address it....Before starting work on the next full release of the .NET Framework, we will review the Connect data to help us identify and address the top customer reported issues." So there we have it. A bug that can crash almost any application -- maybe it will be fixed some time in 2009 or 2010. Maybe not; this bug might never make the cut.
The answer, of course, is to cover your buttons. Since the release of ASP.NET 2.0 a new Web site paradigm has begun to appear: the page with a curtain of decoration that vanishes to reveal content. A less drastic approach is to specify every potentially troublesome control with visibility hidden. Then at the end of page markup add JavaScript to make them visible. By the time a browser reaches that point it will (probably) have interpreted Microsoft's critical elements and can do postbacks correctly.
Subscribe to Posts [Atom]