313614 - JS component fastload dependencies on new dir provider entry

Status: RESOLVED WORKSFORME

(Core :: XPCOM, defect)

Description

[Boris Zbarsky [:bzbarsky]]

It looks like the JS component fastload code makes use of the new ProfLDS directory service entry.  Such an entry was added to the XREDirProvider, but nowhere else.  I'm trying to figure out what implications, if any, this has for:

1) Seamonkey
2) Embeddors

In particular, do they have to make any changes to take advantage of JS component loading?  Or do anything to make sure it doesn't malfunction?  Reading the code it looks to me like fastload will fall back on the "old" profile location and either get something (in which case everything Just Works) or get null (in which case we'll disable JS component fastload).  Is that correct?

Comment 1

[Benjamin Smedberg]

In order for JS component fastload to work correctly, the fastload file location has to be available before XPCOM startup takes place. Currently only the toolkit profile manager impl has enough information to provide this location before XPCOM startup. The way this is supposed to work is that ProfLDS won't be available in seamonkey/embedders, and so we won't normally fastload JS components. There are cases in seamonkey where we could fastload js components under the following conditions:

Run #1
Start XPCOM (no fastload file)
Load JS component for autoreg (no fastload file)
Start profile (fastload file now available)
Save fastload file (JS component fastload information now avaialable)

Run #2
Start XPCOM (no fastload file)
Don't need the JS component yet! (e.g. closeallwindows, and it's a release build so no autoreg)
Start profile
Now load JS component (should fastload)

Comment 2

[Doug Turner (:dougt)]

mass reassigning to nobody.