I ran into this problem
while creating a website that had a _change event coded. It worked fine
the first time through, but whenever the user hit the back button, the _change
event would fire even though the user hadn't changed anything.
I discovered the problem
was NOT a bug. Instead it is caused by a peculiar interaction between the
ASP.NET view state mechanism (which allows pages to 'remember' your control
states) and the browser's cache, which in my case was IE 6.0.
Basically, the browser overrode the HTML rendered by
ASP.NET's view state mechanism with its cached contents. This might be
fine on old style ASP pages, but with ASP.NET web forms, the fact that the cache
'remembered' the new setting of my control, forced the _change event to fire,
even though the user hadn't selected it after hitting back.
Once you understand the
problem, the fix is simple, just disable the browser's caching as the first line
in your Page Load. You should do this for all ASP.NET form pages that have
event handling. Turning off caching won't affect performance, because
these type of pages load dynamically every time, anyway.
Hope this saves you some