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
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 you say a bit
On Fri, Dec 28, 2012 at 3:52 AM, Neil n...@parkwaycc.co.uk 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
10 matches
Mail list logo
