looking at nsChromeRegistry::GetOverlayDataSource(), it make sense why it doesn't get loaded. we build up the file to the overlay rdf file by doing this: // Retrieve the mInner data source. nsCAutoString overlayFile = package; overlayFile += "/"; overlayFile += provider; overlayFile += "/"; overlayFile += "overlays.rdf"; provider is messenger, not messenger/content eventually, when we move addressbook back to chrome/addressbook, this problem will go away. until then, I'm going to take the contents of ns/dist/bin/chrome/messenger/content/addressbook/overlays.rdf and put it into ns/dist/bin/chrome/messenger/overlays.rdf I'm assuming this broke with a chrome re-org. there may be other overlays.rdf files that are not loaded because of this same problem. I'll go look for them.
er, I meant ns/dist/bin/chrome/messenger/content/overlays.rdf
this means any ab overlays will not show up, including the AIM-AB overlays. I've got the work around in my tree. (rhp needs this so my absynch overlay ui will show up.)
adding prass to the cc list. my workaround was to add the contents of addressbook/content/overlays.rdf to messenger/content/overlays.rdf
I added comments to the overlays.rdf files involved to prevent confusion.
hyatt, can you fix this with your other chrome registry hacking?
Assignee: waterson → hyatt
Component: RDF → XP Toolkit/Widgets
I thought the fix was going to be moving addressbook up, out of mailnews or is there a general bug that hyatt needs to fix?
Actually, hard-coded overlays.rdf files from the source tree are now dead. What this file once did has been moved into a manifest.rdf file, and the corresponding overlays.rdf is generated by the app. This bug is either invalid, or a dupe. Let's call it a dupe. *** This bug has been marked as a duplicate of 39248 ***
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.