Summary: | custom constructors (like HTMLOptionElement) are not called during "new HTMLOptionElement" | ||
---|---|---|---|
Product: | WebKit | Reporter: | Eric Seidel (no email) <eric> |
Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | ap, sam |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Mac | ||
OS: | OS X 10.5 | ||
Bug Depends on: | 21846 | ||
Bug Blocks: | 21886 |
Description
Eric Seidel (no email)
2008-10-23 16:21:26 PDT
This doesn't actually depend on bug 21846, but it's related at least. :) 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. 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. 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. |