[Webkit-unassigned] [Bug 139179] HTMLSelectElement add() should support index as second argument

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=139179

--- Comment #33 from Shivakumar J M <shiva.jm at samsung.com> ---
(In reply to comment #32)
> By the way, what the spec says is that HTMLSelectElement.add() should behave
> the same way as HTMLOptionsCollection.add():
> https://html.spec.whatwg.org/multipage/forms.html#dom-select-add
> 
> However, in WebKit, HTMLOptionsCollection.add() only supports an index as
> second argument (not an HTMLElement).
> 
> I think HTMLOptionsCollection.add() should be updated in the same patch to
> make sure both behave the same way (and according to spec).


Dear  Chris,

      Thanks for the inputs, below are some observations:


      1) Adding question marks to indicate that the arguments are nullable seems to work fine, also added new add() api below the old add() api. But no need to make argument1 as nullable, only second argument is fine as below:
[ObjCLegacyUnnamedParameters, RaisesException] void add([Default=Undefined] optional HTMLElement element, [Default=Undefined] optional HTMLElement? before);

     2) With above changes all tests worked fine, but add(element1,Undefined), adds element1 to begining of list, but it should add element1 to end of list. Tried making [Default=Null] for second argument, but did not compile. Default value for second argument should be null.

     3) Yes, right HTMLOptionsCollection also needs to change, but here they are using custom code instead of generated code. so should we remove custom code and make add() api to use generated code ? i.e same as HTMLSelectElement.
Or modify generated code ?. Will try both methods and tests to update patch.

Thanks

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141224/656284a4/attachment-0002.html>