Bug 21842 – custom constructors (like HTMLOptionElement) are not called during "new HTMLOptionElement"

• Status: RESOLVED
• Resolution: INVALID
• Component: DOM

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

This doesn't actually depend on bug 21846, but it's related at least. :)

[Sam Weinig]

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.

[Alexey Proskuryakov]

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.

[Eric Seidel (no email)]

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.