410177 - Drop nsISupportsArray usage from Address Book where possible

Status: RESOLVED FIXED

(MailNews Core :: Address Book, defect)

Description

[Mark Banner (:standard8)]

As nsISupportsArray is obsolete and isn't supported by the frozen API very well, we should drop it.

This bug will do the necessary patches for the address book code. Note that it won't cover usages where we are forced to by RDF, or by nsITreeView (bug 407956).

Comment 1

[Mark Banner (:standard8)]

Attachment: Fix enumerator usages

This patch should fix the remaining enumerator usages where we currently create an nsISimpleEnumerator via an nsISupportsArray.

Comment 2

[Mark Banner (:standard8)]

Attachment: [checked in] Fix enumerator usages

Bah, correct patch this time.

Comment 3

[David :Bienvenu]

Comment on attachment 294838 [details] [diff] [review]
[checked in] Fix enumerator usages

thx, Mark

Comment 4

[Mark Banner (:standard8)]

Attachment: [checked in] Fix nsAbBSDirectory

This fixes the nsAbBSDirectory usage of nsISupportsArray to use a nsCOMArray instead. Much more sensible in this case.

The next patch will cover the public interfaces provided by the address book, which covers a bit more code and I'm still working on.

Comment 5

[[e-mail]]

Comment on attachment 295027 [details] [diff] [review]
[checked in] Fix nsAbBSDirectory

I have to say that nsAbBSDirectory::DeleteDirectory is the worst code I've seen this year. Here's some code that's not quite visible in your context:

> DIR_Server *server;
> mServers.Get(directory, &server);

So far, so good: we get the DIR_Server object from the directory.

>   GetDirectories getDirectories(server);
>-  mServers.Enumerate(GetDirectories_getDirectory, (void *)&getDirectories);

And then we enumerate the servers and append all those whose DIR_Server is the one we just looked up and append them to an array.

In other words, the array only ever has one element: the original directory.

Comment 6

[Mark Banner (:standard8)]

(In reply to comment #5)
> (From update of attachment 295027 [details] [diff] [review])
> I have to say that nsAbBSDirectory::DeleteDirectory is the worst code I've seen
> this year.

That's not hard considering the date ;-)

>Here's some code that's not quite visible in your context:
> 
> > DIR_Server *server;
> > mServers.Get(directory, &server);
> 
> So far, so good: we get the DIR_Server object from the directory.
> 
> >   GetDirectories getDirectories(server);
> >-  mServers.Enumerate(GetDirectories_getDirectory, (void *)&getDirectories);
> 
> And then we enumerate the servers and append all those whose DIR_Server is the
> one we just looked up and append them to an array.
> 
> In other words, the array only ever has one element: the original directory.

Actually, I think you are wrong. Looking up the file a bit, nsAbBSDirectory gets directories from the factories, for each of the directories it gets, it "Put(childDir, aServer)" for each one:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/addrbook/src/nsAbBSDirectory.cpp&rev=1.43&mark=92-95,104,117#73

The outlook case is the only one that will exercise this at the moment:

http://bonsai.mozilla.org/cvsblame.cgi?file=/mozilla/mailnews/addrbook/src/nsAbOutlookDirFactory.cpp&rev=1.17&mark=106,113,115#75

So I think we do have to support the possibility of multiple directories with the same server for the time being (one day we'll drop nsDirPrefs altogether).

Comment 7

[Mark Banner (:standard8)]

Comment on attachment 295027 [details] [diff] [review]
[checked in] Fix nsAbBSDirectory

re-requesting reviews based on my comment 6.

Comment 8

[[e-mail]]

Comment on attachment 295027 [details] [diff] [review]
[checked in] Fix nsAbBSDirectory

OK, so I can't see a better way of doing this.

>-  GetDirectories* getDirectories = (GetDirectories*)aClosure;
I'd leave this in, but you can change it to a static_cast if you prefer.

>-  mServers.Enumerate(GetDirectories_getDirectory, (void *)&getDirectories);
I'd leave this in, but you can change it to an intrinsic cast if you prefer.

Comment 9

[Mark Banner (:standard8)]

Attachment: Fix nsIAbDirectory::DeleteCards

This removes nsISupportsArray from nsIAbDirectory::DeleteCards and some of the usages related to that.

I was going to do the rest of the nsISupportsArray instances in this patch, but then realised it was going to be getting a bit too big.

Comment 10

[Mark Banner (:standard8)]

Attachment: Fix nsIAbDirectory::DeleteCards v2

Opps, forgot one change (missing header addition).

Comment 11

[[e-mail]]

Comment on attachment 295497 [details] [diff] [review]
Fix nsIAbDirectory::DeleteCards v2

>+      nsCOMPtr<nsIAbCard> card(do_QueryElementAt(aCards, i, &rv));
>       NS_ENSURE_SUCCESS(rv, rv);
>+
>+      nsCOMPtr<nsIAbMDBCard> dbcard(do_QueryInterface(card, &rv));
>       NS_ENSURE_SUCCESS(rv, rv);
(Aside: I wonder why one doesn't inherit from the other...)

>-        retCode = aCardList->GetElementAt(i, getter_AddRefs(element)) ;
>-        NS_ENSURE_SUCCESS(retCode, retCode) ;
>-        nsCOMPtr<nsIAbCard> card (do_QueryInterface(element, &retCode)) ;
>-        
>-        NS_ENSURE_SUCCESS(retCode, retCode) ;
>+        nsCOMPtr<nsIAbCard> card(do_QueryElementAt(aCardList, i, &retCode));
>+        NS_ENSURE_SUCCESS(retCode, retCode);
You no longer assign to element here, so you should remove it and replaces its other uses with card. Ironically that's not the bug that the compiler caught, its complaint is this, which looks as if it might be harder to fix:

nsAbOutlookDirectory.cpp(1264) : error C2664: 'nsAbOutlookDirectory::DeleteCards' : cannot convert parameter 1 from 'nsCOMPtr<nsISupportsArray>' to 'nsIArray *'

This is for the call in CommitAddressList to DeleteCards(oldList).

Comment 12

[Mark Banner (:standard8)]

Attachment: Fix nsIAbDirectory::DeleteCards v3

This should hopefully fix the outlook compilation issues. Note that I haven't tried it as I don't have the build env at the moment.

I have also duplicated the GetChildCards function (nsISupportsArray version), this means I can delay changing m_AddressList from a nsISupportsArray to a nsIArray for the next patch - as that affects quite a bit more of the code base.

Comment 13

[[e-mail]]

(In reply to comment #12)
>Created an attachment (id=295811)
>This should hopefully fix the outlook compilation issues.
nsAbOutlookDirectory.cpp(279) : error C2664: 'NS_NewArrayEnumerator' : cannot convert parameter 2 from 'nsCOMPtr<nsIMutableArray>' to 'nsISupportsArray *'
nsAbOutlookDirectory.cpp(285) : error C2065: 'rv' : undeclared identifier
nsAbOutlookDirectory.cpp(321) : error C2065: 'element' : undeclared identifier

Comment 14

[[e-mail]]

Comment on attachment 295811 [details] [diff] [review]
Fix nsIAbDirectory::DeleteCards v3

>+  nsCOMPtr<nsIMutableArray> resultsArray(do_CreateInstance(NS_ARRAY_CONTRACTID,
>+                                                           &retCode));
You don't seem to check this retCode either.

Comment 15

[Mark Banner (:standard8)]

Attachment: Fix nsIAbDirectory::DeleteCards v3

Another attempt at fixing Outlook compilation, hopefully I've fixed all the errors.

Comment 16

[[e-mail]]

Comment on attachment 295967 [details] [diff] [review]
Fix nsIAbDirectory::DeleteCards v3

This compiles, but...

>+    nsCOMPtr<nsIMutableArray> cardList;
>     nsresult retCode ;
>+
>     mCardList.Reset() ;
>     if (mIsQueryURI) {
>         retCode = StartSearch() ;
>+        cardList = do_CreateInstance(NS_ARRAY_CONTRACTID);
>     }
>+    else
>+        retCode = GetChildCards(cardList, nsnull);
This looks wrong; you always want an instance of an array.

Comment 17

[Mark Banner (:standard8)]

Attachment: [checked in] Fix nsIAbDirectory::DeleteCards v4

Fixes creation of the array before calling childCards (and hence, tidies up those lines of code a bit).

Comment 18

[Mark Banner (:standard8)]

Attachment: Fix address lists/selected addresses view.

Fixes nsIAbDirectory::addressLists and nsIAbView::GetSelectedAddresses.

Needs testing before I request reviews though.

Comment 19

[Prasad Sunkari [:prasad]]

Attachment: Fix nsIAbDirectory and nsIAbView

Removes nsISupportsArray from nsIAbDirectory and nsIAbView.  Merged parts from Standard8's patch for address lists/selected addresses.

Build was successful and seemed to work fine on Linux and Windows.

Comment 20

[Mark Banner (:standard8)]

Comment on attachment 315151 [details] [diff] [review]
Fix nsIAbDirectory and nsIAbView

This is missing the required changes in mail/

   // XXX todo
   // fix this, ugh
   // This attribute servers two purposes 
   // depending if the directory is a mail list.
   // If not mail list directories are stored here
   // If so mail list card entries are stored here
-  attribute nsISupportsArray addressLists;
+  attribute nsIMutableArray addressLists;

Please add the comment I added in attachment 296710 [details] [diff] [review]

-	readonly attribute nsISupportsArray selectedAddresses; 
+    readonly attribute nsIArray selectedAddresses; 

ditto re comment

Index: mailnews/addrbook/public/nsIAbView.idl
...
 #include "nsISupports.idl"
-#include "nsISupportsArray.idl" 
+#include "nsIArray.idl" 

Please remove the nsIArray.idl include and make it an interface nsIArray;

-      		var descNode = document.createElement("description");   
-          address = addressList.GetElementAt(i).QueryInterface(Components.interfaces.nsIAbCard).primaryEmail;    
-          displayName = addressList.GetElementAt(i).QueryInterface(Components.interfaces.nsIAbCard).displayName;  
+      	  var descNode = document.createElement("description");   
+          var card = addressList.queryElementAt(i, Components.interfaces.nsIAbCard);
+

Indentation

+  if (!m_AddressList) {
+    nsresult rv;
+    m_AddressList = do_CreateInstance(NS_ARRAY_CONTRACTID, &rv);
+    NS_ENSURE_SUCCESS(rv, rv);
+  }

Please use the 
if ()
{
  ...
}

style of brackets here and in other c++ files in this patch.

-        nsCOMPtr<nsISupports> pSupport;
-        rv = pAddressLists->GetElementAt(i, getter_AddRefs(pSupport));
-        if (NS_FAILED(rv))
-            break;
-
-        nsCOMPtr<nsIAbDirectory> listDir(do_QueryInterface(pSupport, &rv));
+        nsCOMPtr<nsIAbDirectory> listDir(do_QueryElementAt(pAddressLists, i, &rv));
         if (NS_FAILED(rv))
             break;
-        nsCOMPtr<nsIAddrDBListener> dbListener(do_QueryInterface(pSupport, &rv));
+        nsCOMPtr<nsIAddrDBListener> dbListener(do_QueryInterface(listDir, &rv));
         if (NS_FAILED(rv))
             break;

we don't actually need to QI from listDir to dbListener - we can just QueryElementAt straight to nsIAddrDBListener.

-    rv = dbdirectory->ClearDatabase ();
-    return rv;
+    return rv = dbdirectory->ClearDatabase ();

nice try, you just don't need to assign to rv (and please drop the space before the brackets).

-  NS_ASSERTION(!m_AddressList || m_AddressList->IndexOf(aDirectory) < 0,
-               "Replacing?");
+  PRUint32 pos;
+  NS_ASSERTION(!m_AddressList || 
+      NS_FAILED(m_AddressList->IndexOf(0, aDirectory, &pos)), "Replacing?");

Please put an if _DEBUG around this. Although its not much, I'd like to make it clear that the pos is for debug only.

+				if (m_IsMailList) {
+					PRUint32 pos;
+					if(m_AddressList && NS_SUCCEEDED(m_AddressList->IndexOf(0, card, &pos)))
+						m_AddressList->RemoveElementAt(pos);
+				}
+                retCode = NotifyItemDeletion(card) ;

I think a few tabs crept in here (and in other places)

Finally, I'm not quite sure I can give you the official review on this patch as its very much like my attachment 296710 [details] [diff] [review].

Comment 21

[Prasad Sunkari [:prasad]]

Attachment: Fix nsIAbDirectory and nsIAbView - v2

Neil, can you review this patch.  Updated this patch as per comments by Standard8

> 
> Finally, I'm not quite sure I can give you the official review on this patch as
> its very much like my attachment 296710 [details] [diff] [review].
> 

It will be, because when I found many places where your patch was better when I compared them after doing mine.  Eg: (1) I used nsIArray instead of nsIMutable array and (2) I did not know of nsArrayUtils, I used nsIArray->QueryElementAt at all places before seeing your patch ;)

Comment 22

[[e-mail]]

Comment on attachment 316047 [details] [diff] [review]
Fix nsIAbDirectory and nsIAbView - v2

>       foundDirectories[i].directory.addressLists.
>-              SetElementAt(foundDirectories[i].index, gEditCard.card);
>+              replaceElementAt(foundDirectories[i].index, gEditCard.card);
Nit: In other places you neatened code like this to start with a dot.

>+  if ( node ) {
if (node) {

>+  if ( visible )
>+    node.removeAttribute("collapsed");
>+  else
>+    node.setAttribute("collapsed", "true");
This is equivalent to
node.collapsed = !visible;
which is almost worth inlining.

> NS_IMETHODIMP nsAbMDBDirProperty::GetDbRowID(PRUint32 *aDbRowID)
> {
>-	*aDbRowID = m_dbRowID;
>-	return NS_OK;
>+  *aDbRowID = m_dbRowID;
>+  return NS_OK;
> }
> 
> NS_IMETHODIMP nsAbMDBDirProperty::SetDbRowID(PRUint32 aDbRowID)
> {
>-	m_dbRowID = aDbRowID;
>-	return NS_OK;
>+  m_dbRowID = aDbRowID;
>+  return NS_OK;
> }
Nit: this bug isn't about reindenting random methods.

>+  PRUint32 i, count;
>+  m_AddressList->GetLength(&count);
>+  for (i = 0; i < count; i++) 
>+  {
>+    nsCOMPtr<nsIAbDirectory> pList(do_QueryElementAt(m_AddressList, i));
>+    if (mailList == pList)
>+      return NS_OK;
>+  }
Can't you use indexOf to tell that the list (card below) exists?
(Tip: make sure you always add nsIAbDirectory pointers to the array.)

>+  *aHasDirectory = PR_FALSE;
>+
>+  PRUint32 pos;
>+  if(m_AddressList && NS_SUCCEEDED(m_AddressList->IndexOf(0, aDirectory, &pos)))
>+    *aHasDirectory = PR_TRUE;
PRUint32 pos;
*aHasDirectory = m_AddressList && NS_SUCCEEDED(m_AddressList->IndexOf(0, aDirectory, &pos));

Or at least put a space between if and ( [you do that in other places too].

>+nsresult nsAbOutlookDirectory::GetChildNodes(nsCOMPtr<nsIMutableArray> &aNodes)
Surely an nsIMutableArray* aNodes works just as well?
(I don't understand why GetChildCards does it like that either.)

>+    nsAbWinHelperGuard mapiAddBook (mAbWinType);
Nit: no space before ( here!

>+        {
>+        PRINTF(("Cannot get nodes.\n"));
>+        return NS_ERROR_FAILURE;
>+    }
Nit: indentation of { here is wrong and again below.

Comment 23

[Prasad Sunkari [:prasad]]

Attachment: Fix nsIAbView and nsIAbDirectory - Updated as per Neil's comments.

Fixed as per Neil's review comments.
r=neil.

Comment 24

[Prasad Sunkari [:prasad]]

Attachment: Fix nsIAbView and nsIAbDirectory - Updated to the latest trunk

updated to the latest trunk.
Need help testing it on Windows and MAC.

Comment 25

[Prasad Sunkari [:prasad]]

Comment on attachment 321778 [details] [diff] [review]
Fix nsIAbView and nsIAbDirectory - Updated to the latest trunk

obsoleting the patch due to more changes on the trunk as well as errors on windows build.

Comment 26

[Prasad Sunkari [:prasad]]

Attachment: Fix nsIAbView and nsIAbDirectory - Latest Trunk

The patch became obsolete due to a few patches on the trunk.
Updated to the latest trunk and fixed a windows build error.

Comment 27

[Dan Mosedale (:dmosedale, :dmose)]

Comment on attachment 321992 [details] [diff] [review]
Fix nsIAbView and nsIAbDirectory - Latest Trunk

Sorry for the delay; this looks good.  sr=dmose, with a few tweaks:

>Index: mail/components/addrbook/content/abCardOverlay.js
>===================================================================
>RCS file: /cvsroot/mozilla/mail/components/addrbook/content/abCardOverlay.js,v
>retrieving revision 1.23
>diff -u -8 -p -r1.23 abCardOverlay.js
>--- mail/components/addrbook/content/abCardOverlay.js	13 Dec 2007 18:12:18 -0000	1.23
>+++ mail/components/addrbook/content/abCardOverlay.js	21 May 2008 19:27:28 -0000
>@@ -188,19 +188,19 @@ function OnLoadNewCard()
>   }
>   moveToAlertPosition();
> }
> 
> // @Returns The index in addressLists for the card that is being saved;
> //          or |-1| if the card is not found.
> function findCardIndex(directory)
> {
>-  var i = directory.addressLists.Count();
>+  var i = directory.addressLists.length;
>   while (i-- > 0) {
>-    var card = directory.addressLists.QueryElementAt(i, Components.interfaces.nsIAbCard);
>+    var card = directory.addressLists.queryElementAt(i, Components.interfaces.nsIAbCard);
>     if (gEditCard.card.equals(card))
>       break;
>   }
>   return i;
> }

It looks to me that a lot of XPConnect boundary-crossing could be avoided if, rather than fixing findCardIndex, you throw it out entirely and replace it with a call to nsIArray.indexOf wrapped in a try/catch.

>@@ -437,43 +437,40 @@ function cvSetNode(node, text)
>   }
> 
>   return visible;
> }
> 
> function cvAddAddressNodes(node, uri)
> {
>   var visible = false;
>-  if ( node )
>-  {
>-    var displayName = "";
>-    var address = "";
> 
>+  if (node) {
>     var editList = GetDirectoryFromURI(uri);
>     var addressList = editList.addressLists;
> 
>     if (addressList) {
>-      var total = addressList.Count();
>+      var total = addressList.length;
>       if (total > 0) {
>         while (node.hasChildNodes()) {
>           node.removeChild(node.lastChild);
>         }
>         for (i = 0;  i < total; i++ ) {
>           var descNode = document.createElement("description");
>-          address = addressList.GetElementAt(i).QueryInterface(Components.interfaces.nsIAbCard).primaryEmail;
>-          displayName = addressList.GetElementAt(i).QueryInterface(Components.interfaces.nsIAbCard).displayName;
>+          var card = addressList.queryElementAt(i, Components.interfaces.nsIAbCard);
>+
>           descNode.setAttribute("class", "CardViewLink");
>           node.appendChild(descNode);
> 
>           var linkNode = document.createElementNS("http://www.w3.org/1999/xhtml", "a");
>           linkNode.setAttribute("id", "addr#" + i);
>-          linkNode.setAttribute("href", "mailto:" + address);
>+          linkNode.setAttribute("href", "mailto:" + card.primaryEmail);

It's unrelated to the changes you're making, but I suspect that it's possible to exploit this URI creation in weird ways by having a remote (e.g. LDAP) addressbook with a hostile email address or convincing someone to import a hostile vCard.  Can you file a spinoff bug to look into that?

>   // XXX todo
>   // fix this, ugh
>   // This attribute servers two purposes 
>   // depending if the directory is a mail list.
>   // If not mail list directories are stored here
>   // If so mail list card entries are stored here
>-  attribute nsISupportsArray addressLists;
>+  //
>+  // Note: Altering this array *will* also alter the locally stored array.
>+  attribute nsIMutableArray addressLists;

Since you're touching this, how about tweaking the comment to be in doxygen format and using @note.
The comment doesn't quite make sense, because there is no locally stored array.  I assume you're trying to make the point that a reference to the live array in use by the card object is being returned, not a static copy of that array?  If so, maybe use phrasing along those lines for clarity...

>Index: mailnews/addrbook/resources/content/abCardOverlay.js

For this and other forked files, it looks to me like the same comments apply as the ones I made for the mail/ files above.

>@@ -121,49 +122,45 @@ NS_IMETHODIMP nsAbMDBDirFactory::GetDire
> /* void deleteDirectory (in nsIAbDirectory directory); */
> NS_IMETHODIMP nsAbMDBDirFactory::DeleteDirectory(nsIAbDirectory *directory)
> 
> [...]
>
>-        pAddressLists->RemoveElement(pSupport);
>+        
>+        PRUint32 pIndex;
>+        if(NS_SUCCEEDED(pAddressLists->IndexOf(0, listDir, &pIndex)))
>+          pAddressLists->RemoveElementAt(pIndex);

What's the reasoning for calling GetIndexOf rather than just using i here?  Could other threads be doing stuff behind our back?  Same question about AddAddressToList.

Comment 28

[[e-mail]]

Wasn't the old code bogus too? It counted from 0 to N but removed the elements during processing! Shouldn't we simply clear pAddressLists after the loop?

Comment 29

[Dan Mosedale (:dmosedale, :dmose)]

Ah, I understand the reasoning in the patch now: my proposed change would have preserved the old bug.  Neil's right that the old code was bogus, and his proposed solution sounds like a good change to me.

nsAbOutlookDirectory::DeleteCards has similar logic, and it should be able to avoid the extra IndexOf by making the loop count down, rather than up, I think.

Still sr+ given the suggested tweaks.

Comment 30

[Prasad Sunkari [:prasad]]

Attachment: [checked in] Updates as per comments by dmose.

Updated the patch as per comments by dmose and Neil.
Carrying r=neil and sr=dmose.

Comment 31

[Mark Banner (:standard8)]

Comment on attachment 323276 [details] [diff] [review]
[checked in] Updates as per comments by dmose.

Checking in mail/components/addrbook/content/abCardOverlay.js;
/cvsroot/mozilla/mail/components/addrbook/content/abCardOverlay.js,v  <--  abCardOverlay.js
new revision: 1.24; previous revision: 1.23
done
Checking in mail/components/addrbook/content/abCardViewOverlay.js;
/cvsroot/mozilla/mail/components/addrbook/content/abCardViewOverlay.js,v  <--  abCardViewOverlay.js
new revision: 1.13; previous revision: 1.12
done
Checking in mail/components/addrbook/content/abCommon.js;
/cvsroot/mozilla/mail/components/addrbook/content/abCommon.js,v  <--  abCommon.js
new revision: 1.33; previous revision: 1.32
done
Checking in mailnews/addrbook/public/nsIAbDirectory.idl;
/cvsroot/mozilla/mailnews/addrbook/public/nsIAbDirectory.idl,v  <--  nsIAbDirectory.idl
new revision: 1.61; previous revision: 1.60
done
Checking in mailnews/addrbook/public/nsIAbView.idl;
/cvsroot/mozilla/mailnews/addrbook/public/nsIAbView.idl,v  <--  nsIAbView.idl
new revision: 1.14; previous revision: 1.13
done
Checking in mailnews/addrbook/resources/content/abCardOverlay.js;
/cvsroot/mozilla/mailnews/addrbook/resources/content/abCardOverlay.js,v  <--  abCardOverlay.js
new revision: 1.71; previous revision: 1.70
done
Checking in mailnews/addrbook/resources/content/abCardViewOverlay.js;
/cvsroot/mozilla/mailnews/addrbook/resources/content/abCardViewOverlay.js,v  <--  abCardViewOverlay.js
new revision: 1.42; previous revision: 1.41
done
Checking in mailnews/addrbook/resources/content/abCommon.js;
/cvsroot/mozilla/mailnews/addrbook/resources/content/abCommon.js,v  <--  abCommon.js
new revision: 1.118; previous revision: 1.117
done
Checking in mailnews/addrbook/resources/content/abMailListDialog.js;
/cvsroot/mozilla/mailnews/addrbook/resources/content/abMailListDialog.js,v  <--  abMailListDialog.js
new revision: 1.54; previous revision: 1.53
done
Checking in mailnews/addrbook/src/nsAbCardProperty.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbCardProperty.cpp,v  <--  nsAbCardProperty.cpp
new revision: 1.94; previous revision: 1.93
done
Checking in mailnews/addrbook/src/nsAbDirProperty.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbDirProperty.cpp,v  <--  nsAbDirProperty.cpp
new revision: 1.66; previous revision: 1.65
done
Checking in mailnews/addrbook/src/nsAbDirProperty.h;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbDirProperty.h,v  <--  nsAbDirProperty.h
new revision: 1.26; previous revision: 1.25
done
Checking in mailnews/addrbook/src/nsAbMDBDirFactory.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbMDBDirFactory.cpp,v  <--  nsAbMDBDirFactory.cpp
new revision: 1.32; previous revision: 1.31
done
Checking in mailnews/addrbook/src/nsAbMDBDirProperty.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbMDBDirProperty.cpp,v  <--  nsAbMDBDirProperty.cpp
new revision: 1.25; previous revision: 1.24
done
Checking in mailnews/addrbook/src/nsAbMDBDirectory.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbMDBDirectory.cpp,v  <--  nsAbMDBDirectory.cpp
new revision: 1.87; previous revision: 1.86
done
Checking in mailnews/addrbook/src/nsAbManager.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbManager.cpp,v  <--  nsAbManager.cpp
new revision: 1.181; previous revision: 1.180
done
Checking in mailnews/addrbook/src/nsAbOSXDirectory.mm;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbOSXDirectory.mm,v  <--  nsAbOSXDirectory.mm
new revision: 1.18; previous revision: 1.17
done
Checking in mailnews/addrbook/src/nsAbOutlookDirectory.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbOutlookDirectory.cpp,v  <--  nsAbOutlookDirectory.cpp
new revision: 1.59; previous revision: 1.58
done
Checking in mailnews/addrbook/src/nsAbOutlookDirectory.h;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbOutlookDirectory.h,v  <--  nsAbOutlookDirectory.h
new revision: 1.19; previous revision: 1.18
done
Checking in mailnews/addrbook/src/nsAbView.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsAbView.cpp,v  <--  nsAbView.cpp
new revision: 1.69; previous revision: 1.68
done
Checking in mailnews/addrbook/src/nsAddrDatabase.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsAddrDatabase.cpp,v  <--  nsAddrDatabase.cpp
new revision: 1.170; previous revision: 1.169
done
Checking in mailnews/addrbook/src/nsDirectoryDataSource.cpp;
/cvsroot/mozilla/mailnews/addrbook/src/nsDirectoryDataSource.cpp,v  <--  nsDirectoryDataSource.cpp
new revision: 1.90; previous revision: 1.89
done
Checking in mailnews/compose/src/nsMsgCompose.cpp;
/cvsroot/mozilla/mailnews/compose/src/nsMsgCompose.cpp,v  <--  nsMsgCompose.cpp
new revision: 1.564; previous revision: 1.563
done
Checking in mailnews/compose/src/nsMsgCompose.h;
/cvsroot/mozilla/mailnews/compose/src/nsMsgCompose.h,v  <--  nsMsgCompose.h
new revision: 1.119; previous revision: 1.118

Comment 32

[Mark Banner (:standard8)]

(In reply to comment #31)
> (From update of attachment 323276 [details] [diff] [review])
> Checking in mail/components/addrbook/content/abCardOverlay.js;
...

For testers, check items relating to the address book, cards and mailing lists (sending, searching etc for possible regressions). All types of AB.


Of the nsISupportsArray items that are now left in the address book code:

nsAbAutoCompleteSession.cpp
nsAbLDAPAutoCompleteSession.cpp

will be replaced by a completely new version via bug 370306,

nsAbView.cpp

these instances would be replaced by bug 407956,

nsAbRDFDataSource.cpp

would be removed by the proposed rdf removal, bug number as yet not filed, but not part of this bug.

Therefore closing this bug as fixed as the title includes "where possible" and we have done all possible instances at the moment.

Comment 33

[Dan Mosedale (:dmosedale, :dmose)]

Prasad: what's the bug number of the spinoff bug?