Closed Bug 202563 Opened 17 years ago Closed 2 months ago

Need better support for loading XBL bindings asynchronously

Categories

(Core :: XBL, defect)

x86
All
defect
Not set

Tracking

()

RESOLVED WONTFIX

People

(Reporter: emaijala+moz, Unassigned)

Details

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...
Priority: -- → P2
Target Milestone: --- → mozilla1.6alpha
"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...)
QA Contact: ian → xbl
Assignee: bzbarsky → nobody
Priority: P2 → --
Target Milestone: mozilla1.6alpha → ---

XBL is now disabled in Firefox (Bug 1583314) and is in the process of being removed from Gecko (Bug 1566221), so closing bugs requesting changes to its implementation as wontfix.

Status: NEW → RESOLVED
Closed: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.