Re: Use of instanceof SomeDOMInterface in chrome and extensions
On Mon, Dec 31, 2012 at 11:23 AM, Andreas Gal g...@mozilla.com wrote: I think it would be extremely surprising to chrome JS authors if instanceof works differently in content and chrome, resulting in very hard to diagnose bugs. What if we made it work that way in content as well? Yes, ultra-dirty and all that, but in terms of least-surprise, stuff like iframe.contentDocument.documentElement instanceof Node being false is pretty surprising to most authors too. Rob -- Jesus called them together and said, “You know that the rulers of the Gentiles lord it over them, and their high officials exercise authority over them. Not so with you. Instead, whoever wants to become great among you must be your servant, and whoever wants to be first must be your slave — just as the Son of Man did not come to be served, but to serve, and to give his life as a ransom for many.” [Matthew 20:25-28] ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
Boris Zbarsky wrote: Alternately, we could do something where the proto chain of an Xray for a content object passes through the corresponding chrome prototypes, not through Xrays for the content window's prototypes. That would presumably make el instanceof el.ownerDocument.defaultView.HTMLAnchorElement return false and might have other issues. I don't think that would work, because you wouldn't expect the Xray for a content object to have methods that you added to the prototype of the chrome object. (I would actually expect the proto of an Xray for a content object to be an [xpconnect wrapped native prototype], but I'm probably asking too much.) -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
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
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/29/12 11:19 AM, smaug wrote: And doesn't work for data documents which don't have defaultView Hrm... Yes. You mean something like Node.is(element, HTMLAnchorElement); ? Or HTMLAnchorElement.isHTMLAnchorElement(element) or HTMLAnchorElement.is(element) or something -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On Sun, Dec 30, 2012 at 10:12 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/30/12 4:50 PM, Bobby Holley wrote: It seems like we could just do (1) with very little code, by just checking the JSClass. Right now we can even do it simply by delegating to QI (see hasInstanceInterface annotations in Bindings.conf), but yes, adding code to check the protoid chain in the JSClass would be very simple. Well, you mentioned that one of the costs of maintaining this behavior would be maintaining the nsIDOMFoo interfaces right? So I'm suggesting that we use codegen and the JSClass to short-circuit that stuff. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On Dec 31, 2012, at 8:08 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/30/12 2:16 PM, Robert O'Callahan wrote: How bad would it be to make expr instanceof expression resolving to WebIDL interface special-cased to re-map the RHS to the appropriate WebIDL interface object for expr? In terms of implementation complexity on our end, it's trivial as long as we don't follow the WebIDL spec and make things like HTMLAnchorElement actual Function instances. In terms of specs and getting other UAs to go along... I don't know. In this sea of terrible choices, how about making HTMLAnchorElement an actual function, but having it return object for typeof? That should be reasonably Web-compatible. Andreas -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
On 12/30/12 10:34 PM, Andreas Gal wrote: In this sea of terrible choices, how about making HTMLAnchorElement an actual function, but having it return object for typeof? Apart from being an ES violation (which we're in the business of anyway, at the moment), what does that actually buy us? Right now, in my tree, HTMLAnchorElement is an object with a [[Call]], so typeof returns function and it has a JSClass that lets us override the behavior of instanceof. But if it were an actual function then we couldn't change how instanceof behaves (it would just look up the proto chain of the LHS for the value of HTMLAnchorElement.prototype), right? What do we get from making its typeof return object? Feel like I'm missing something, Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Use of instanceof SomeDOMInterface in chrome and extensions
In case anyones' eyes glazed over reading my last post, here's my reduced 2c: 1) How do we want this to work going forward for chrome touching content? |obj instanceof Node| should return true. 2) How do we want this to work going forward for web pages touching other web pages? |obj instanceof Node| should return false until the standards community decides something to the contrary and specs it. 3) Can we make #1 and #2 look identical? No. 3) If #2 doesn't match what WebIDL/ES5 does right now, can we get the relevant specs and other UAs to align with what we want? See (2). I'm in favor of Mozilla taking the back seat on this one - I'm happy to implement it if other vendors are pushing for it, but think we have bigger things to be pushing for ourselves. bholley ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
