764277 - New DOM bindings codegen doesn't register classes with constructors

Status: RESOLVED FIXED

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

Description

[Johnny Stenback (:jst)]

Attachment: 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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Note bug 764234 comment 1.

Comment 2

[Boris Zbarsky [:bzbarsky]]

And in particular, we _do_ want to register things that don't have constructors, as long as they have interface objects.

Comment 3

[Johnny Stenback (:jst)]

Cc:ing William too in case this matters for his work on notifications...

Comment 4

[Peter Van der Beken [:peterv]]

Attachment: 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.

Comment 5

[Peter Van der Beken [:peterv]]

Attachment: v1

Comment 6

[Peter Van der Beken [:peterv]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bef4bf064981

Comment 7

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/bef4bf064981