Bug 13448

Summary:

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

Product:

WebKit

Reporter:

Darin Adler <darin>

Component:

Forms

Assignee:

Sam Weinig <sam>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

adele, ap, sam

Priority:

Keywords:

InRadar

Version:

523.x (Safari 3)

Hardware:

Mac

OS:

OS X 10.4

Attachments:

Description	Flags
test case (ready for layout tests directory)	none
patch	mitz: review+

Darin Adler

Reported 2007-04-22 10:30:38 PDT

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

Attachments
test case (ready for layout tests directory) (740 bytes, text/html) 2007-04-22 10:31 PDT, Darin Adler	no flags	Details
patch (6.36 KB, patch) 2007-04-24 08:07 PDT, Sam Weinig	mitz: review+	Details Formatted Diff Diff
View All Add attachment proposed patch, testcase, etc.

Darin Adler

Comment 1 2007-04-22 10:31:05 PDT

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

Darin Adler

Comment 2 2007-04-22 10:31:59 PDT

<rdar://problem/5152055>

Darin Adler

Comment 3 2007-04-22 12:19:52 PDT

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

Comment 4 2007-04-23 08:57:12 PDT

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

Comment 5 2007-04-24 08:02:58 PDT

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

Comment 6 2007-04-24 08:07:34 PDT

Created attachment 14158 [details] patch

mitz

Comment 7 2007-04-24 08:15:03 PDT

Comment on attachment 14158 [details] patch r=me

Sam Weinig

Comment 8 2007-04-24 08:26:39 PDT

Landed in r21070.

Darin Adler

Comment 9 2007-04-24 09:32:17 PDT

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

Note You need to log in before you can comment on or make changes to this bug.