Well, no sooner does one find a bug than hyatt decides to rewrite great reams of code. This was crashing in the now-deceased nsXBLService::GetContentList(). I'll see if this condition/crash is fixed in the new code tomorrow. Thanks for the nice test case.
Okay, I will really check it now (jrgm using trudelle's login).
I just tried it on 0.8. doesn't cause a crash anymore but it returns a null when there are no anonymous children. shouldn't it return an empty array instead?
Right you are. No crash, but that method should return the empty list, rather than |null| to be consistent with other DOM methods.
easy workaround, can fix later, ->future
This "patch" fixes the problem by doing what we would have done in nsXULElement::GetChildNodes if box had a binding. I can't say I really understand why this is necessary. Hoping David "xpconnect" Bradley can explain.
This is not good. I'm marking this as wontfix.
I'm not saying that there is any pressing need to fix this, but I think this is still a valid bug. DOM methods such as getElementsByTagName() and childNodes() always return a NodeList, which is a, possibly zero-length, list. They don't return null when they have no members. I don't see why it's preferable to have getAnonymousNodes() not return an empty list.
Well, then we'd have to make a cheesy internal method that did return null just to deal with this. The problem is this method is called all the time as you walk down a frame tree, and you'll end up allocating all of these node lists for the frames that don't have anonymous content. I would guess that Blake's patch would spike page load times by 5-10%.
Anyway, the binding manager method should return null. I'll accept a patch to DocumentXBL's method to make a nodelist, but the binding manager method can't be changed.
> > I don't see why it's preferable to ... > > ... would spike page load times by 5-10% ... Ok, now I see :-].
Yes, I didn't expect to check this in, hence "patch"; I notice we hit the !binding case many, many times.
I'm still confused though about how this method is just returning an object, though, and not a nodelist (as shown by alert(typeof retval)), given http://lxr.mozilla.org/seamonkey/source/dom/public/idl/xbl/nsIDOMDocumentXBL.idl#46 Can someone explain that to me, just for my own knowledge?
blake: try alert(retval) alert(typeof window) will yield 'object' too. It is not "just an object", but it *is* an object (not a string, number, function, or undefined).
This is a mass change. Every comment has "assigned-to-new" in it. I didn't look through the bugs, so I'm sorry if I change a bug which shouldn't be changed. But I guess these bugs are just bugs that were once assigned and people forgot to change the Status back when unassigning.