Created attachment 632566 [details] [diff] [review] Hacky fix. 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.
Note bug 764234 comment 1.
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...
Created attachment 633136 [details] [diff] [review] v1 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
Created attachment 633141 [details] [diff] [review] v1
Attachment #633141 - Flags: review?(jst) → review+
Target Milestone: --- → mozilla16
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.