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
On Thu, Dec 27, 2012 at 1:56 PM, Neil wrote:
> Jonas Sicking wrote:
>
>> On Dec 18, 2012 4:15 AM, "Neil" wrote:
>>
>>>
>>> While investigating the possibility of switching nsCOMArray away from
>>> nsVoidArray it occurred to me that nsCOMArray takes steps to ensure internal
>>> consistency before
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. [..
Jonas Sicking wrote:
On Dec 18, 2012 4:15 AM, "Neil" wrote:
While investigating the possibility of switching nsCOMArray away from
nsVoidArray it occurred to me that nsCOMArray takes steps to ensure internal
consistency before releasing removed elements; this is because it's potentially
p
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
9 matches
Mail list logo
