While working on another bug, I noticed this regression. Setting an input element's value to JavaScript null now gives us "null" instead of "". I tested Gecko and it works like the old version of Safari -- gives "".
Created attachment 14137 [details] test case (ready for layout tests directory)
<rdar://problem/5152055>
This is actually a bug in the HTML DOM bindings. We have keywords that translate null values into strings with various rules, but I couldn't immediately find the appropriate one to use in HTMLInputElement.idl to fix this. The ones for properties seem to focus on the getter side rather than the setter side. Somehow we overlooked this when converting HTMLInputElement to auto-generated DOM. The old hand-written DOM binding must have handled this.
The property keyword that is appropriate here is [ConvertNullToNullString]. It seems that the "name" attribute suffers from the same issue. I am going to investigate what other attributes might also be affected.
It seems that all of the attribute that set/get DOMStrings for HTMLInputElement suffer from the same issue except 'type' which treats any unknown value the same as the empty string so the value 'null' is just ignored. I have a patch which fixes these issues but we should file a followup patch to look into what other elements might also have this issue. We should also consider, if it makes sense, making conversion from js null to the empty string the default.
Created attachment 14158 [details] patch
Comment on attachment 14158 [details] patch r=me
Landed in r21070.
I understand that this is right for the setter side. But is it right for the getter side too?