188030 - nsICSSLoader needs a facelift

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P1)

Description

[Boris Zbarsky [:bzbarsky]]

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.  ;)

Comment 1

[Boris Zbarsky [:bzbarsky]]

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....

Comment 2

[Boris Zbarsky [:bzbarsky]]

Attachment: patch that shows the problem, debug warts and all (I need this out of my tree ;) )

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.  :(

Comment 4

[Boris Zbarsky [:bzbarsky]]

Fixed by checkin for bug 293825.