Closed Bug 188030 Opened 20 years ago Closed 18 years ago

nsICSSLoader needs a facelift

Categories

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

x86
Linux
defect

Tracking

()

RESOLVED FIXED
mozilla1.5alpha

People

(Reporter: bzbarsky, Assigned: bzbarsky)

References

Details

Attachments

(1 file)

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.  :(
Blocks: 185236
Priority: -- → P1
Target Milestone: --- → mozilla1.5alpha
Depends on: 183131
Blocks: 183131
No longer depends on: 183131
Depends on: 293825
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.