User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8.1.12) Gecko/20080129 Iceweasel/2.0.0.12 (Debian-2.0.0.12-2) Build Identifier: Thundebird 2.0.0.12 During the developement of the SOGo Connector, we have noticed a bug that prevents all valid addressbooks from appearing in the composition window. Although GroupDAV (embedding a moz-abmdbdirectory), regular MDB and LDAP directories appears. CardDAV (?name=moz-abdavdirectory) don't. The XUL code that shows this bug is the following: <menupopup id="addressbookList-menupopup" datasources="rdf:addressdirectory" ref="moz-abdirectory://" sortActive="true" sortDirection="ascending" sortResource="http://home.netscape.com/NC-rdf#DirTreeNameSort"> <template> <rule nc:IsMailList="false"> <menuitem uri="..." label="rdf:http://home.netscape.com/NC-rdf#DirName" value="rdf:http://home.netscape.com/NC-rdf#DirUri"/> </rule> </template> </menupopup> ... in abContactsPanel.xul Reproducible: Always Steps to Reproduce: 1. 2. 3.

(In reply to comment #0) > User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8.1.12) > Gecko/20080129 Iceweasel/2.0.0.12 (Debian-2.0.0.12-2) > Build Identifier: Thundebird 2.0.0.12 > > During the developement of the SOGo Connector, we have noticed a bug that > prevents all valid addressbooks from appearing in the composition window. > Although GroupDAV (embedding a moz-abmdbdirectory), regular MDB and LDAP > directories appears. CardDAV (?name=moz-abdavdirectory) don't. Without seeing the code, its very hard to debug/help you with this. This would be better on a support forum (e.g. newsgroup mozilla.dev.apps.thunderbird rather than here). However, some thoughts: - Have you implemented an RDF Resource inherited object for CardDAV? (e.g. see how nsAbLDAPDirectory inherits from nsAbDirectoryRDFResource). - Have you implemented an nsIAbDirFactory instance for your directory? - How do you know this is a valid directory? - Are you sure GetIsMailList is returning false?

I will attach the module that implements the code a bit later... Meanwhile here is the answer to your questions: The way it is implemented is through a JS component. So it answers to the nsAbDirectory interface. There is also a nsIAbDirFactory that was implemented, although I am not certain how useful it is... I'll copy an excerpt too. How I know it is a valid directory... At least because it appears in the regular addressbook window, it interacts well with the other components: autocomplete, search,... and it does make correct requests to the server. The only anomalies left with it is the one mentionned here and the fact that removing such a directory will keep an entry in the localstore.rdf file... Although it removes well from the addressbook window and from the prefs.js.

Regarding the forum advise, I think it is a good one for the remaining questions. But I do think this really is a bug. Maybe some code that isn't modular enough?

I uploaded both the directory code and the directory factory code...

Do the CardDAV directories appear in any of the menus at the following locations? - Advanced Address Book Search - New Card Dialog - New Mailing List Dialog The xul is very similar in these cases so I think its worth checking.

They don't. But it's expected for the 2 last dialogs because CardDAV entries are always read-only and are not mailing lists: <template> <rule nc:IsWriteable="false"/> <rule nc:IsMailList="false"> <menuitem uri="..." label="rdf:http://home.netscape.com/NC-rdf#DirName" value="rdf:http://home.netscape.com/NC-rdf#DirUri"/> </rule> </template> But both the advanced search dialog and the contact panels only requires the ab to not be a mailing list: <template> <rule nc:IsMailList="false"> <menuitem uri="..." oncommand="onChooseDirectory(event.target)" label="rdf:http://home.netscape.com/NC-rdf#DirName" value="rdf:http://home.netscape.com/NC-rdf#DirUri"/> </rule> </template> ... which is indeed the same code that the contacts panel uses.

Hi, Any news on this? Thanks

Sorry, this dropped off my radar. I've just installed your extension in the TB 2.0 build and have been able to reproduce your problem. However, I still can't say for certain where the real issue lies. The one item that I did notice, is that if I get an instance of the carddav nsIAbDirectory, and query directoryProperties.URI I get: carddav://http://host/SOGo/dav/userName/Contacts/public/ Although I can't say for certain, I'm wondering if the rdf service (or something) is getting upset about this, as it essentially has two schemes defined, making it an illegal URI. Could you try (at least temporarily) making it a legal URI like carddav://ab1 and see if it appears in the menus with that? Meanwhile, I'll do a debug build of TB branch and see if I get any useful assertions popping up.

Hi Mark, I tested if the folder would appear with an entry like this: carddav://SOGo/dav/wsourdeau/Contacts/public/ .. and it didn't work. Could it be that the directory factory is missing an operation somewhere?

I've now had a look at a debug build of TB 2.0. From the assertions and warnings that I'm getting it looks like this is your problem: http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/rdf/base/idl/nsIRDFResource.idl&rev=1.11&mark=64-65#60 You can't implement that interface in javascript (because its not scriptable). Unfortunately various bits of the code rely on this function when dealing with rdf resources. Having looked at the places in core where this is affecting you, I don't think we'd be able to get them changed for the scriptable versions on the Thunderbird 2.x branch (which is typically for security/stability fixes only). On trunk (Thunderbird 3.x), I'm hoping to remove the need for rdf from the address book before the release - I'm not certain it'll happen yet, but it has a good chance. This would, of course, mean this problem wouldn't affect you. So I'm thinking we're unfortunately going to have to resolve this bug as "wontfix", the bug being that you can't implement extensions to address books entirely in js due to the rdf problems.

Is there any way it could be implemented using the mechanisms proposed by the nsIClassInfo inteface?

(In reply to comment #13) > Is there any way it could be implemented using the mechanisms proposed by the > nsIClassInfo inteface? > It appears we've got no way out (without taking your implementation to binary), because of that interface. The data types between js & c++ aren't compatible, and that function doesn't follow xpcom rules either.

Confirming, based on Mark's comments. I agree that this is too disruptive to fix on branch, but I think it wants to block Tb3, given that we really want better pluggability. Marking as a blocker. Even if RDF isn't completely excised by then, we could replace the use of templates here with some code that constructs the menu from JS using scriptable RDF interfaces, like Joey has done in other places. For the branch, it might be possible to do something like that as a workaround: the idea being to use either the DOM or an overlay to hide or replace that menupopup element with a different menupopup element that's JS-drive.

Definitely. A js-driven menupopup-widget of addressbooks, based on querying from the root abook is definitely in order. I'd be happy to move this widget up in priority if it'd help people. If 2.0 is a deal-breaker, you could even port the widget back in an extension and with some creative overlays, fix the problem there.

Excellent idea. I think I will override the popup that way.

Just expanding the summary slightly so I know what this bug is when I see it.

Wolfgang, a couple of days ago, I checked in bug 449260, that has changed most of the menus that list address books into xbl/js driven ones. The only menus that haven't changed would be: - Preferences Pane (which I think are js based anyway) - The menus where you select the specific AB for "is/isn't in my address book" on the search/filter dialog (the main menu there is now js based). Would you be able to try these again on trunk? I'd be very interested to see if this has resolved most of your problems.

Retriaging according to new policy for flags. https://wiki.mozilla.org/Thunderbird:Release_Driving

(In reply to comment #19) > Wolfgang, a couple of days ago, I checked in bug 449260, that has changed most > of the menus that list address books into xbl/js driven ones. ... > Would you be able to try these again on trunk? I'd be very interested to see if > this has resolved most of your problems. Wolfgang, we've now got all the menus switched over, any chance you could take a look again? I think its unlikely that we'll completely switch away from rdf in the Thunderbird 3 cycle, but it could still happen. Either way it'd be good to know if the changes we have done are good enough. Thanks.

I've not had any feedback if this is fixed or not, but I believe it should have been fixed by bug 449260, therefore marking as fixed with that bug. Please feel free to reopen if its really causing an issue on trunk still.