Sorry for taking so long to weigh in here. There are two main cases to consider.
Content->Content, same-origin (via transparent CrossCompartmentWrappers): This is the most web-visible area, and thus the one where we should be the most careful. I don't think we should unilaterally implement any kind of non-ECMA hacks that the web doesn't already depend on. It would only further fracture the ecosystem that we're working so hard to mend. If we think that such behavior would seriously improve the web as a platform, we should get consensus from other vendors and get Hixie to put an explicit ECMA deviation in HTML5 (which has been done before). Chrome->Content, Xray delegation: This is the primary case that Boris was asking about. In the long term, I'd like for Xray wrappers to behave more logically with respect to the prototype chain than they have in the past. I believe that Peter has already taken the first step by giving us meaningful Xrays to DOM prototypes and interface objects, but the resolution still happens via the one-stop-shop resolveNativeProperty (via XrayWrapper::getPropertyDescriptor) which queries the entire spectrum of inherited properties directly on then Xray-ed object. I would prefer this to happen properly via the wrapped prototype chain, so that native properties on Xrayed objects could be shadowed via expandos on the (Xrayed) prototype chain. This seems most correct to me, and IMO best captures the spirit of Xrays: we want the Xrayed objects to behave as normally as possible, but just be free of any tampering by script associated with their scope. So while Boris' suggestion of remapping the prototypes of Xray-ed prototypes would work (indeed, we've proven it's possible with COWs), I don't think we should do it. It violates the above-mentioned spirit of Xrays with very unintuitive behavior, which is likely to lead to the kinds of inconsistencies that Gal mentioned. In particular, content DOM objects from multiple scopes would then appear to share prototypes. What's more, this puts us in a near-impossible position when Xrays are waived (via .wrappedJSObject or XPCNativeWrapper.unwrap()): do we remap the prototypes (violating the guarantee of transparency) or not (making the behavior of waived objects inconsistent with other objects for seemingly arbitrary reasons)? Given that, it would appear that we have two options: (1) Implement a HasInstance hook for Paris Binding interface objects in chrome scopes only. (2) Force addons to change. (2) is always an option, but IMO it should be a pretty high bar. We can only do so much of that, and I'm not convinced that the compatibility hacks here will cost of very much. It seems like we could just do (1) with very little code, by just checking the JSClass. But maybe I'm missing something? Cheers, bholley _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
