Closed Bug 857417 Opened 12 years ago Closed 12 years ago

Make it impossible to mis-order nsISupports and nsWrapperCache in WebIDL object inheritance

Categories

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

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla23

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(1 file, 1 obsolete file)

https://vargajan.wordpress.com/2013/04/02/moving-stuff-to-new-dom-bindings/ points out a known gotcha in our bindings code: For C++ objects that inherit from nsISupports, the nsISupports pointer needs to come first. It's a bit of a pain, because the nsISupports the JS object is holding on to is not always the canonical nsISupports (e.g. nsContentList) and because we can't do the trick with static_cast and reinterpret_cast in cases when there is multiple inheritance from nsISupports, since the static_cast won't compile. But what I think we _can_ do is to assert, when we're isupports and wrappercached, that static_cast and reinterpret_cast to nsWrapperCache give _different_ answers. That would at least catch the case Jan ran into, I think.
This will obviously still let buggy code compile, but should fatally assert as soon as you try to wrap the object...
Whiteboard: [need review]
Attached patch Even betterSplinter Review
Maybe I don't need the assertISupportsInheritance bit anymore...
Attachment #732917 - Flags: review?(khuey)
Attachment #732647 - Attachment is obsolete: true
Attachment #732647 - Flags: review?(khuey)
Flags: in-testsuite+
Whiteboard: [need review]
Target Milestone: --- → mozilla23
Depends on: 859617
Depends on: 859675
Relanded as https://hg.mozilla.org/integration/mozilla-inbound/rev/ef9509eb9a4c now that I've fixed the classes that failed these asserts.
Status: NEW → RESOLVED
Closed: 12 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.

Attachment

General

Created:
Updated:
Size: