On 12/28/2012 11:18 AM, Boris Zbarsky wrote:
On 12/28/12 4:12 AM, Neil wrote:
In the interim I believe foo.constructor.name == "Array" was popular,
but I see that doesn't work for (e.g.) new Image().
This should work (modulo bugs in exactly the cases where we've hacked
the instanceof behavior)
Bobby Holley wrote:
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.
Some nodes, such as HTMLImageElement nodes, expose more properties on
their "Xray" wrappers than on their content wrappers. Does this apply
On 2012-12-28 5:34 PM, Boris Zbarsky wrote:
On 12/28/12 2:00 PM, Neil wrote:
But if you're keeping nsIDOMNode, then you might as well keep the most
popular interface that derives from it.
Probably true, unless we decide we don't care _that_ much about editor
perf and move it to a tearoff
Bobby Holley wrote:
You can do things like "new contentWindow.XMLHttpRequest"
That's a good example, thanks.
--
Warning: May contain traces of nuts.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-
Den 29-12-2012 20:19smaug skrev:
On 12/27/2012 12:18 PM, Boris Zbarsky wrote:
We have a bunch of chrome and extension code that does things like
"instanceof HTMLAnchorElement" (and likewise with other DOM interfaces).
The problem is that per WebIDL spec and general ECMAScript sanity this
should
Another way of looking at the problem: should there be an API to determine
if an object implements a particular WebIDL interface? I hope we agree the
answer is yes... In that case, what would we call it? Can we call it
something that doesn't sound like "instanceOf", and explain with a straight
face
On 12/31/12 8:25 PM, Boris Zbarsky wrote:
They were, as roc points out, apathetic. Or rather, there was some talk
about it being a good idea but no concrete proposals and nothing
actually happening.
That said, I posted one more time on public-script-coord (and bcced
es-discuss) just to see if
On 12/31/12 5:08 PM, Bobby Holley wrote:
I think we should consider any reliance on this behavior a bug for
now
Fine. Then the question becomes: how do we _not_ rely on this behavior?
As smaug pointed out upthread there is actually no sane way to do that
right now.
It also sounds from yo
On Tue, Jan 1, 2013 at 2:26 PM, Bobby Holley wrote:
> But IIUC the magic already works via XPConnect/nsDOMClassInfo quirks. This
> is why Gaia developers are starting to rely on it, and why Boris is
> wondering whether he should propagate that magic into WebIDL bindings.
>
> So we've already been
On Mon, Dec 31, 2012 at 5:12 PM, Robert O'Callahan wrote:
> I interpreted Boris to mean other vendors were apathetic rather than
> opposed.
>
> If it was just apathy, then I think we should go for it and make
> instanceof magic for WebIDL interface objects in both content and chrome,
> and try to
On Tue, Jan 1, 2013 at 2:08 PM, Bobby Holley wrote:
> It also sounds from your initial post that other vendors weren't very
> receptive to the idea. If so, that's a shame. Maybe we could try again?
>
I interpreted Boris to mean other vendors were apathetic rather than
opposed.
If it was just ap
On Mon, Dec 31, 2012 at 4:45 PM, Boris Zbarsky wrote:
> On 12/31/12 4:26 PM, Bobby Holley wrote:
>
>> Well, if we're talking about JS-implemented WebAPIs, then that stuff
>> should
>> be running as chrome, potentially in the content process (unless I'm
>> mistaken - I'm still a bit behind on all
On 12/31/12 4:26 PM, Bobby Holley wrote:
Well, if we're talking about JS-implemented WebAPIs, then that stuff should
be running as chrome, potentially in the content process (unless I'm
mistaken - I'm still a bit behind on all the b2g architecture). If we're
talking about web apps, then they're s
On Mon, Dec 31, 2012 at 3:58 PM, Boris Zbarsky wrote:
> On 12/30/12 11:14 PM, Bobby Holley wrote:
>
>> 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 touc
On 12/30/12 11:14 PM, Bobby Holley wrote:
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
On Mon, Dec 31, 2012 at 6:22 AM, Neil wrote:
> Bobby Holley wrote:
>
> 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
>
Bobby Holley wrote:
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
What does mean
Boris Zbarsky wrote:
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. ;)
Yeah, well I still wish Xrays had been imple
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
On 12/27/2012 12:18 PM, Boris Zbarsky wrote:
We have a bunch of chrome and extension code that does things like "instanceof
HTMLAnchorElement" (and likewise with other DOM interfaces).
The problem is that per WebIDL spec and general ECMAScript sanity this
shouldn't work: instanceof goes up the
On 12/28/12 2:00 PM, Neil wrote:
But if you're keeping nsIDOMNode, then you might as well keep the most
popular interface that derives from it.
Probably true, unless we decide we don't care _that_ much about editor
perf and move it to a tearoff
-Boris
___
Boris Zbarsky wrote:
On 12/28/12 3:54 AM, Neil wrote:
How does removing nsIDOM* stuff without removing nsIDOMNode reduce
memory usage
There are elements that implement multiple nsIDOM*, last I checked.
But if you're keeping nsIDOMNode, then you might as well keep the most
popular interfac
On 12/28/12 4:12 AM, Neil wrote:
In the interim I believe foo.constructor.name == "Array" was popular,
but I see that doesn't work for (e.g.) new Image().
This should work (modulo bugs in exactly the cases where we've hacked
the instanceof behavior) for WebIDL bindings, actually. We could als
On 12/28/12 3:54 AM, Neil wrote:
How does removing nsIDOM* stuff without removing nsIDOMNode reduce
memory usage
There are elements that implement multiple nsIDOM*, last I checked.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
Neil wrote:
Boris Zbarsky wrote:
Unfortunately, that's not how instanceof works in JS. Try it with
Object instead of HTMLAnchorElement...
Making foo instanceof Array false across globals was an
extension-breaking change when it happened. Fortunately we have
Array.isArray these days.
In
Boris Zbarsky wrote:
Unfortunately, that's not how instanceof works in JS. Try it with
Object instead of HTMLAnchorElement...
Making foo instanceof Array false across globals was an
extension-breaking change when it happened. Fortunately we have
Array.isArray these days.
--
Warning: May c
Justin Dolske wrote:
On 12/27/12 3:33 PM, Neil wrote:
Justin Dolske wrote:
What happens today (and in the future), with something like:
// Hello, I am chrome code adding an anchor to content
var noob = document.createElement("a");
gBrowser.contentDocument.body.appendChild(noob);
If you're
Boris Zbarsky wrote:
On 12/27/12 1:54 PM, Neil wrote:
Presumably this involves completely removing all XPIDL DOM interfaces
from HTML nodes, thus saving one vtable entry per node?
There are cases in which we can remove nsIDOM* stuff without removing
nsIDOMNode/Element/HTMLElement. Which is
On 12/27/12 11:20 PM, Boris Zbarsky wrote:
On 12/27/12 2:49 PM, Justin Dolske wrote:
Hmm. My first reaction is to gently challenge if this really has to
change
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
On 12/27/12 2:49 PM, Justin Dolske wrote:
Hmm. My first reaction is to gently challenge if this really has to
change
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).
On 12/27/12 1:54 PM, Neil wrote:
More importantly it suggests 311 for the similar "instanceof
Components.interfaces.nsIDOMHTMLAnchorElement" (or equivalent) often
used in components and modules of course.
Yeah. We'd obviously need to do something about that...
Presumably there's no easy way
On 12/27/12 3:33 PM, Neil wrote:
What happens today (and in the future), with something like:
// Hello, I am chrome code adding an anchor to content
var noob = document.createElement("a");
gBrowser.contentDocument.body.appendChild(noob);
If you're lucky, you append a XUL element to the
Justin Dolske wrote:
What happens today (and in the future), with something like:
// Hello, I am chrome code adding an anchor to content
var noob = document.createElement("a");
gBrowser.contentDocument.body.appendChild(noob);
If you're lucky, you append a XUL element to the content docu
On 12/27/12 2:18 AM, Boris Zbarsky wrote:
The arguably "right" way to do the "el instanceof HTMLAnchorElement"
test is:
el instanceof el.ownerDocument.defaultView.HTMLAnchorElement
Needless to say this sucks.
Eew, indeed.
So the question is how we should make the above work sanely. [..
Boris Zbarsky wrote:
We have a bunch of chrome and extension code that does things like
"instanceof HTMLAnchorElement" (and likewise with other DOM interfaces).
c-c MXR suggests 305 cases of "instanceof HTML.*Element". There are also
18 "instanceof XUL.*Element, 13 "instanceof Element", 14 "i
We have a bunch of chrome and extension code that does things like
"instanceof HTMLAnchorElement" (and likewise with other DOM interfaces).
The problem is that per WebIDL spec and general ECMAScript sanity this
shouldn't work: instanceof goes up the proto chain looking for the thing
on the rig
50 matches
Mail list logo
