We've noticed this unfortunate bug only recently, on a page that had been working without issue for a very long time. It is specific to Google Chrome version 27, and I am currently using version 26.
The bug:(clicking anywhere inside of the control - the scroll bar being the focus of the issue - causes a complete postback [provided you set the AutoPostBack attribute to true])
The bug could be at a higher level of scripting, and I'm not sure it affects all of our listboxes. It seems unlikely as we have many, on multiple pages, and we would be getting calls if all of them exhibited this behavior.
Our solution contained two options, with another option being less classy:
1) Impractical: to wait for an update for Google Chrome, or use version 26 explicitly. This is impractical for a large userbase which doesn't have permissions for installation or the ability to roll back to a previous version. It also doesn't work if you, for whatever reason, absolutely must test against the latest version of Chrome.
2) We have access to Telerik controls which enable us to use RadListBox instead, slightly more viewstate overhead which may not be a good solution for you, if it's an option at all. This was the option we chose, as the RadListBox escapes the problem behavior.
A distant third, substantially less appealing solution: Find some other alternative for displaying your data, such as a dropdown list, possibly with a secondary subselecting control if you're dealing with a particularly large set of information. It's more work, in the interim, and you would likely wish to revert your changes when a fix was made.
I know all of these are mediocre solutions, but they're possible workarounds. Sorry if this isn't much help.
AutoPostBack="true"
equal tofalse
does it still happen? – CallahanAutoPostBack="true"
, the eventListBox1_SelectedIndexChanged
will not be invoked. And the problem is resolved. But that event should be called. – Wilkinson