On Fri, Dec 28, 2012 at 3:52 AM, Neil wrote:
> Jonas Sicking wrote:
>
>> There's nothing special about XPCOM objects here.
>>
>
> While this is clearly true, I still feel it's getting away from my original
> point, because I was trying to compare with nsCOMArray.
I guess my argument is: Sure, nsT
On Sat, 2012-12-22 at 15:11 -0800, Justin Dolske wrote:
> On 12/21/12 8:17 AM, JP Rosevear wrote:
>
> > ** Goals
> >
> > 1) [...] Social/Location (TBD) - (overall jst)
> > [...]
> > + Drive deep integration of a tier one location platform (dougt)
>
> Hmm. I don't understand what this is. Could yo
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
Jonas Sicking wrote:
There's nothing special about XPCOM objects here.
While this is clearly true, I still feel it's getting away from my
original point, because I was trying to compare with nsCOMArray.
--
Warning: May contain traces of nuts.
___
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
12 matches
Mail list logo
