21842 2008-10-23 16:21:26 -0700 custom constructors (like HTMLOptionElement) are not called during "new HTMLOptionElement" 2008-10-25 08:19:23 -0700 1 1 1 Unclassified WebKit DOM 528+ (Nightly build) Mac OS X 10.5 RESOLVED INVALID P2 Normal --- 21846 21886 1 eric webkit-unassigned ap sam oldest_to_newest 96446 0 eric 2008-10-23 16:21:26 -0700 custom constructors (like HTMLOptionElement) are not called during "new HTMLOptionElement" Why? JSValuePtr jsDOMWindowHTMLOptionElementConstructor(ExecState* exec, const Identifier&, const PropertySlot& slot) { if (!static_cast<JSDOMWindow*>(asObject(slot.slotBase()))->allowsAccessFrom(exec)) return jsUndefined(); return JSHTMLOptionElement::getConstructor(exec); } we call JSHTMLOptionElement::getConstructor(exec), but JSHTMLOptionElement has no custom implementation of getConstructor, because the idl doesn't have GenerateConstructor defined. Seems we need a CustomConstructor= idl flag. I expect this is a regression, since otherwise I don't know why we'd have this dead code in WebCore. I'm not even really sure I understand what crazy behavior the custom JSHTMLOptionElementConstructor is supposed to provide. Tentatively marking this as a Regression. Feel free to remove the flag if you have more info to suggest it's not. 96468 1 eric 2008-10-23 18:25:49 -0700 This doesn't actually depend on bug 21846, but it's related at least. :) 96473 2 sam 2008-10-23 19:02:31 -0700 I don't think that new HTMLOptionElement has ever worked. The syntax is new Option(), and that behavior is implemented in JSDOMWindowBase in jsDOMWindowBaseOption() which uses the custom JSHTMLOptionElementConstructor class. We should see if mozilla supports the new HTMLOptionElement syntax and move forward accordingly. 96669 3 ap 2008-10-25 04:24:07 -0700 As Sam said, these "constructors" can not be used for constructing objects, they are only good for extending prototypes. Someone else may be able to better explain this in legalese, but the bug as filed is not valid. 96671 4 eric 2008-10-25 08:19:23 -0700 Ok. There is a valid bug here. But I will file a new one. document.createElement("option").constructor == "[object HTMLElementConstructor"; That seems wrong to me. Since that's the only HTMLElement "subclass" for which that is true. That is due to the fact that HTMLOptionElement has a custom constructor which is not wired up correctly.