Bug 21842 - custom constructors (like HTMLOptionElement) are not called during "new HTMLOptionElement"
Summary: custom constructors (like HTMLOptionElement) are not called during "new HTMLO...
Status: RESOLVED INVALID
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on: 21846
Blocks: 21886
  Show dependency treegraph
 
Reported: 2008-10-23 16:21 PDT by Eric Seidel (no email)
Modified: 2008-10-25 08:19 PDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2008-10-23 16:21:26 PDT
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.
Comment 1 Eric Seidel (no email) 2008-10-23 18:25:49 PDT
This doesn't actually depend on bug 21846, but it's related at least. :)
Comment 2 Sam Weinig 2008-10-23 19:02:31 PDT
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.
Comment 3 Alexey Proskuryakov 2008-10-25 04:24:07 PDT
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.
Comment 4 Eric Seidel (no email) 2008-10-25 08:19:23 PDT
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.