Closed Bug 533401 Opened 10 years ago Closed 10 years ago

Names added through external DOM classinfo don't resolve on global object


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

Not set



Tracking Status
status1.9.2 --- beta5-fixed


(Reporter: peterv, Assigned: peterv)




(2 files)

Attached patch v1Splinter Review
This blocks the CoolIris extension from working in 1.9.2.

The check for the non-null mData->mProtoChainInterface in nsDOMClassInfo::PostCreatePrototype fails (because CoolIris doesn't supply a protochain interface), and so we never define the name on the global object. That check originally was in nsDOMClassInfo::PostCreate where it was fine (only need to set up prototype chain if there's a non-nsISupports interface on the prototype chain), but in PostCreatePrototype it looks unneeded. Only the debugging code needs the check, because it uses mProtoChainInterface to check its name. The code in ResolvePrototype, which gets called from PostCreatePrototype, looks like it can deal with null or nsISupports for the mProtoChainInterface.
Flags: blocking1.9.2?
Attachment #416523 - Flags: review?(jst)
a=beltzner to land on trunk when reviewed
Is it possible to make an automated test case for this so we don't break this in the future again?
Comment on attachment 416523 [details] [diff] [review]

Looks good.
Attachment #416523 - Flags: review?(jst) → review+
Yeah, I've been looking at how to test this.
Attached patch Part 2 v1Splinter Review
We need an additional fix so that |new foo()| also works. Already got r=jst in person on this one.
Attachment #416692 - Flags: review+
Now that we know this fixes everything we need to fix to get cooliris back in business, we should block on this for 1.9.2.
Flags: blocking1.9.2? → blocking1.9.2+

Still working on the test.
Closed: 10 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.2
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.