Closed Bug 764277 Opened 11 years ago Closed 11 years ago

New DOM bindings codegen doesn't register classes with constructors


(Core :: DOM: Core & HTML, defect)

Not set





(Reporter: jst, Assigned: peterv)




(1 file, 2 obsolete files)

Attached patch Hacky fix. (obsolete) — Splinter Review
When we do codegen for a webidl interface that has a constructor we don't generate code that actually registers that interface as a global constructor with the DOM code, which means the codegen alone doesn't make a constructable interface constructable in JS. This stuff happens to work for existing classes, where we already have old bindings that trigger the registration of the constructors, but for new types, we need more.

I hacked up a patch that makes this work, but it's not right, nor pretty. But it's enough to get Bonnie unblocked in bug 764234. The attached patch ends up working, but it registers classes that don't have constructors as well as ones that do, so someone who understands the WebIDL parser, dom binding config guts, and the code generator better than I do (hi peter :) should write an appropriate fix here.
And in particular, we _do_ want to register things that don't have constructors, as long as they have interface objects.
Cc:ing William too in case this matters for his work on notifications...
Attached patch v1 (obsolete) — Splinter Review
Just nullchecking on hash-insertion means we'll have to check for the uninitialized type in DOMCI, which seems wrong. This adds an overwritable eTypeNewDOMBinding type. Still needs testing.
Attachment #632566 - Attachment is obsolete: true
Attached patch v1Splinter Review
Attachment #633136 - Attachment is obsolete: true
Attachment #633141 - Flags: review?(jst)
Attachment #633141 - Flags: review?(jst) → review+
Closed: 11 years ago
Resolution: --- → FIXED
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.