This is most likely your browser remembering the value input - if the outputText is correct, then it isn't Seam/JSF.
I would normally agree, but it behaves the same way in Firefox and IE 6, and I changed the cache settings in IE, and added a nocache line to the code.
Besides, it only "remembers" the value when I change it then cancel.
To expand on the problem a little, if I click on two items in the source page to edit them, I get two independent conversations with two different values for the name. If I change one of them and save it, all is well.
If instead I change one of them and cancel, that value will show up as the "name" input in any other edit window.
Ah, we're using IceFaces (1.6DR5). I had discounted that before because I have this problem with h:inputText as well as ice:inputText, but maybe IceFaces is still controlling the underlying model.
I'll take a look at their hack.
As a followup, I had trouble implementing their workaround (from the Jira bug).
I was cancelling from a popup window, trying to end the conversation, and reload the parent window.
For some reason, when I tried to do this from the action listener, my parent window would hang.
I got it working by implementing both a listener and an action for the cancel button. The listener executes the workaround (clearing the submitted values in the UIComponents), while the action ends the conversation and triggers the parent window to reload.