Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007103008 Minefield/3.0a9pre ID:2007103008 repro: install tabsidebar ( http://www.oxymoronical.com/web/firefox/TabSidebar/development ) open a tab result: the sidebar is empty regressionwindow: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&filetype=match&whotype=match&sortby=Date&hours=2&date=explicit&mindate=1193430360&maxdate=1193444099&cvsroot=%2Fcvsroot -> Bug 345711

The problem is that my code is adding an element to the DOM and expecting it's xbl bound methods to be immediately available. That appears to be no longer the case. Glancing over bug 345711 it does look like that moved adding the binding to later in the process. It seems quite fundamental to me that I shouldn't have to wait before using the methods, right now my only thought is to use a setTimeout hack to get round this.

Just some further info. This is a problem when the code is running as part of the constructor of a different binding. It appears that if the elements are added outside of any other constructor then the binding's methods are available immediately.

This is the faulty extension in case you need to look any more than my explanation.

> This is a problem when the code is running as part of the constructor of a > different binding. Ah. So XBL behavior all along has been that if you enqueue a constructor while inside a constructor execution, the new constructor won't fire until the old one has finished. Which means that you've been calling methods on a binding whose constructor hasn't run yet. Kinda bad idea to start with... > It seems quite fundamental to me that I shouldn't have to wait before using > the methods You already did before if any of the methods depended on the constructor in any way... which you have no way of knowing, in general. Now our behavior is at least consistent: the binding is generally not available until the constructor has fired (modulo the spawn of evil that is PostCreate). Perhaps we should think about firing the nested constructor immediately here, of course, instead of waiting for the outer one to finish. I fully expect that to break things; the question is whether it fixes more than it breaks.

I think I have this fixed. What would help a lot would be a minimal testcase so that I can verify the fix.

Should be fixed by patch in bug 401463, please reopen if it's not.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a9pre) Gecko/2007110109 Minefield/3.0a9pre ID:2007110109 VERIFIED, thanks Jonas