I tested with yesterday's CVS head, and it seems to work fine. Please note that the current LocaleSelector#setLocale(Locale) and setLocaleString(String) do not call the setter methods, which invoke isDirty. I can't find any problems with this, but don't know if the isDirty is important here. No problems at all using the new ThemeSelector#selectTheme(String). As for the auto-submit: First, for the archives, taken from MyFaces wiki: note that for checkboxes and radio buttons you will want to use onclick instead of onchange as IE6 fires the onchange during 'blur' instead of the actual change of these input controls whereas onclick is fired when the value is actually changed for all browsers. Secondly: &quot;gavin.king(a)jboss.com&quot; wrote : I don't see why overloading should be a problem, but if it is, please let me know. I guess I got confused due to (for testing purposes) using BOTH <h:commandButton> and onchange="submit()" within the very same <h:form>. So, I had two dropdowns, one with the button and another with the onchange handler: <h:form ...> | <span class="menuItem"> | <h:selectOneMenu value="#{themeSelector.theme}"> | <f:selectItems value="#{themeSelector.themes}"/> | </h:selectOneMenu> | <h:commandButton action="#{themeSelector.select}" | value="Select Theme"/> | </span> | <span class="menuItem"> | <h:selectOneMenu value="#{themeSelector.theme}" | onchange="submit();" | valueChangeListener="#{themeSelector.select}"> | <f:selectItems value="#{themeSelector.themes}" /> | </h:selectOneMenu> | </span> | </h:form> which yields: <form id="j_id3" name="j_id3" method="post" ...> | <span class="menuItem"> | <select name="j_id3:j_id8" size="1"> | <option value="default" selected="selected">Default</option> | <option value="accessible">Accessible</option> | <option value="printable">Print</option> | </select> | <input type="submit" name="j_id3:j_id10" value="Select Theme" /> | </span> | <span class="menuItem"> | <select name="j_id3:j_id12" size="1" onchange="submit();"> | <option value="default" selected="selected">Default</option> | <option value="accessible">Accessible</option> | <option value="printable">Print</option> | </select> | </span> | </form> Seeing no Javascript above to somehow register which input the user touched last, I guess using two dropdowns (or three, ..., within the same form) to achieve the very same thing is not supposed to be supported (probably the reason why Apache Trinidad supports autoSubmit). Ok, no problem, ready. But if it is supposed to be supported, then I can investigate further. I surely am no JSF expert though. First impression, using Firefox: JSF seems to know which method to invoke, probably because Firefox does not send the button name when using submit() to post the form. However, it sometimes seems to use the wrong value (like the value from another dropdown) to determine what the user has selected. In some quick tests I can simultaneously use both the <h:commandButton> and onchange="submit()" for ThemeSelector, but only if the onchange-version is the first. This also applies to the LocaleSelector, but then the dropdown would still show the previous language as being the selected choice, even though the page would be rendered using the new language. When defining the onchange-version as the second dropdown, then the version with the submit button no longer has any effect. Changing the method names makes no difference. Also the value for immediate does not seem to change the behavior. I also noticed that, when changing the theme, LocaleSelector#setLocaleString is invoked as well, even twice. But when changing the locale, ThemeSelector does not get called. If that rings any alarm bells then please let me know and I can debug some more. But I guess it's not an issue at all. Obviously, only using a single dropdown in the form solves all issues. Thanks, Arjan. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4038396#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...