Bug 13448 – REGRESSION: setting an input element's value to JavaScript null gives "null"

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Darin Adler]

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 "".

[Darin Adler]

Created attachment 14137 [details]
test case (ready for layout tests directory)

[Darin Adler]

<rdar://problem/5152055>

[Darin Adler]

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.

[Sam Weinig]

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.

[Sam Weinig]

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. 

[Sam Weinig]

Created attachment 14158 [details]
patch

Comment on attachment 14158 [details]
patch

r=me

[Sam Weinig]

Landed in r21070.

[Darin Adler]

I understand that this is right for the setter side. But is it right for the getter side too?