This is a spin-off from bug 90337. There are currently many problems with loading XBL bindings asynchronously (which is done for all but chrome URIs). nsXBLService::LoadBindings() starts the load. If the bindings are already or immediately loaded, it proceeds to call the following methods for the new binding: newBinding->SetBoundElement(aContent); newBinding->GenerateAnonymousContent(); newBinding->InstallEventHandlers(); newBinding->InstallImplementation(); newBinding->GetFirstBindingWithConstructor(aBinding); newBinding->HasStyleSheets(aResolveStyle); If the load isn't completed yet, at least some of these methods are never called. And things go haywire if a consumer tries to use a binding before it's loaded anyway (see bug 90337). This means many hacks have been necessary (for example bugs 190433 and 163372) to make things work. Another problem is that a window won't be shown until it's loaded. When showing a dialog this could cause the activation event to be ignored and the window to malfunction (see bug 191896). Quoting bz from bug 90337: "Perhaps this means XBL consumers should not do stupid shit with bound elements until onload fires and XBL binding loading should block onload till the bindings are loaded? This does not help the case when elements are created via DOM methods and then accessed immediately, though....". I'll add more if I remember something.

Targeting optimistically (very) for now...

"Perhaps this means XBL consumers should not do stupid **** with bound elements until onload fires and XBL binding loading..." well, real consumers _always_ do stupid **** with whatever is active under the cursor ;) - it's up to applications to not let them do it when there's a chance to break things. This bug is particularly annoying esp. when you have to fill-up|go-through long|complex forms, and are pushed to do it quickly: not only the url-bar, but usually even input fields do not respond to keystrokes, and can't scroll windows|frames with keyboard (at least I guess it's the same bug, since this happens at same time as on url-bar). Usually, a 'user-mode' simple solution is, switch focus to another window, then back to the unrresponsive one. [M.2003050714, Debian 3 and 2.2] btw: sometimes this happens with NS 4.8 as well, on url-bar at least.

Paolo, the "consumer" in this case IS the application (Firebird/Thunderbird/SeaMonkey/whatever). You're correct that someone should be doing something checks; the only question is whether the core XBL code can do something about this problem, or whether the application that uses XBL has to be coded to handle async loading better (in most cases, I suspect that the core code can't do anything short of loading bindings synchronously...)