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
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
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
On Mon, Dec 31, 2012 at 6:22 AM, Neil n...@parkwaycc.co.uk 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
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
On Mon, Dec 31, 2012 at 3:58 PM, Boris Zbarsky bzbar...@mit.edu 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
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
On Mon, Dec 31, 2012 at 4:45 PM, Boris Zbarsky bzbar...@mit.edu 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 Tue, Jan 1, 2013 at 2:08 PM, Bobby Holley bobbyhol...@gmail.com 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.
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
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,
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
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
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 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
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
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?
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/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/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
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
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:
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
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
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 also
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
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
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
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
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. [...]
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
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
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 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
36 matches
Mail list logo
