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
On 12/30/12 10:53 PM, Andreas Gal wrote:
"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."
You said you want to make it a function. I am just trying to say thats ok, as
"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."
You said you want to make it a function. I am just trying to say thats ok, as
long it says "object" for typeof.
Andreas
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?
On Dec 31, 2012, at 8:08 AM, Boris Zbarsky wrote:
> On 12/30/12 2:16 PM, Robert O'Callahan wrote:
>> How bad would it be to make " instanceof > WebIDL interface>" special-cased to re-map the RHS to the appropriate
>> WebIDL interface object for ?
>
> In terms of implementation complexity on our
On Sun, Dec 30, 2012 at 10:12 PM, Boris Zbarsky 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 i
On 12/30/12 4:43 PM, Neil wrote:
(I would actually expect the proto of an Xray for a
content object to be an [xpconnect wrapped native prototype]
If you expect that for WebIDL objects... you're going to be
disappointed. ;)
-Boris
___
dev-platform
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 t
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
___
On 12/30/12 2:16 PM, Robert O'Callahan wrote:
How bad would it be to make " instanceof " special-cased to re-map the RHS to the appropriate
WebIDL interface object for ?
In terms of implementation complexity on our end, it's trivial as long
as we don't follow the WebIDL spec and make things li
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 ki
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.HTML
On Mon, Dec 31, 2012 at 11:23 AM, Andreas Gal 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 al
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.
Andreas
On Dec 31, 2012, at 12:16 AM, "Robert O'Callahan" wrote:
> On Fri, Dec 28, 2012 at 8:20 PM, Boris Zbarsky wrote:
>
>> Well,
On Fri, Dec 28, 2012 at 8:20 PM, Boris Zbarsky wrote:
> Well, it really has to change as exposed to web content (or we have to
> convince every single other browser to change behavior and get the
> ECMAScript spec changed and so forth).
>
How bad would it be to make " instanceof " special-cased
15 matches
Mail list logo
