Closed Bug 188030 Opened 20 years ago Closed 18 years ago
ICSSLoader needs a facelift
This interface could use some work... for example, the XBL resource loader should not be using LoadStyleLink, since there is no need to insert the sheet in the document. At the moment, however, it has precious few options.... I had some other ideas, but the escape me; that's why I figured I should file the bug. ;)
Well, I just tried a simple change -- taking the "async" version of LoadAgentSheet and trying to actually make it async. This means that even if the sheet is in the chrome cache we deliver the notification asynchronously -- via a PLEvent in this case. So I did that, then saw that the notification was being delivered after onload had fired on the profile manager, causing it to not work so hot. So I tried making the PLEvent I was using implement nsIRequest and adding it to the loadgroup for the document. This worked for some things, but _still_ failed in the one case when the profile manager appends items into a listbox onload(), triggering frame construction and XBL binding loads for them.. the item that should be selected by default ends up unselectable. That looks like a XUL/XBL/whatever bug to me, but it's blocking work on this api.... Anyone have any ideas what's up? Failing all else, I'm tempted to just leave the "async" stuff only bastardly async; of course this forces all callers to deal with the not-really-async crap somehow....
OK, so the problem is as follows: The profile manager, onload() (so once everything is all spic and span) takes the profile list and creates one "listitem" element per profile (using createElement) and sticks them in the listbox. Their creation starts the load of the "listitem" binding (or some binding; I have not bothered to find out which). With my change, that binding loads asynchronously, even though the stylesheet is in the chrome cache at this point. Problem is, right after adding all these elements to the listbox the code tries to select one of them. This fails, most likely because it tries to access DOM stuff that the binding defines and the binding is not loaded yet. Simply putting the attempt to select the profile on a 0-msec timeout makes everything quite happy..... This seems to be a generic problem with XBL -- the lack of ability to tell whether a binding has finished loading or not..... I can certainly hack the profile manager to "work", but I'm not sure what else depends on the current messed-up state of affairs. :(
Priority: -- → P1
Target Milestone: --- → mozilla1.5alpha
Fixed by checkin for bug 293825.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.