17680 - Address Book: Duplicate entry in left pane

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Address Book & Contacts, defect, P1)

Description

[fenella]

Linux (1999-10-29-10 M11)
Win_nt 4.0 (1999-10-29-12 M11)
Mac (1999-10-29-08 M11)
1. Launch Messenger
2. Select Address Book from Task menu

Actual result: In the left pane, Personal Address Book and Collected Addresses
are listed twice.

Expected result: They should be listed only once

This happens on all systems.

Note: I do not see a bug in the database.

Comment 1

[esther]

Changing qa assigned to esther.  Also note, when you select any of the address
books (original or duplicate) the results pane doesn't display the card display
name.

Comment 2

[esther]

After talking to Paul, I will log a separate bug for the Results pane not
showing the Cards Display Name (see my comments above dated 11/01/99)

Comment 3

[hangas]

This problem has gone away for me.  Probably as a result of a fix that waterson
checked in last night.  Marking fixed.

Comment 4

[hangas]

This bug is not closed.  It started showing up on my Mac again.  Will look at
this for M12.

Comment 5

[scottputterman]

I have an idea of what is happening.  I've cc'd Chris because I don't know if
RDF is doing the right thing or if we have to do something differently.

Basically, the address book's tree has a ref of "abdirectory://".  When the tree
is being built, we get into RDFGenericBuilderImpl::CreateContents and do
    rv = gXULUtils->GetElementRefResource(aElement, getter_AddRefs(resource));
When CreateContents ends, the resource is released and since this is the only
ref, the nsABDirectory is destroyed.  However, RDF eventually comes back into
CreateContents again due to EnsureContentGenerated and recreates the root
resource and asks for the children again.  Hence everything appears twice.

The reason this doesn't happen in mail is because we hold onto the root resource
in our code preventing the release in CreateContents from causing any problems.
We do this because we need to compare the root to potential source resources,
but in the address book this case never comes up.  Obviously we can hold onto
the root in the address book and solve this bug.  But, I'm wondering why the
root isn't being held onto in the graph some place?

Comment 6

[Chris Waterson]

Maybe we need an additional call to nsXULElemnt::ForceElementToOwnResource()
thrown in there somewhere. I'll try putting one in RebuildWidgetItem() and see
if that helps.

Comment 7

[lchiang]

release noted for M11.

Comment 8

[scottputterman]

I don't know why this makes a difference but I saw that EnsureContentsGenerated
was getting called for the directory pane and it was getting called from some
XULDocument overlayforwardreference call.  So I explored that and found that if
I took the

ref="abdirectory://" from the xul file and instead in js set the ref with
SetAttribute (as we do in mail) that the duplicates went away.

I don't know if this means there's a problem with the addressbook xul some place
or if there's a problem with the ref code.

the fact that the abdirectory is getting destroyed prematurely doesn't seem to
affect this bug once I change where the ref is set.

Comment 9

[Chris Waterson]

Hmm. I bet that we're trying to construct the template builder twice or
something. I'll take a look.

Comment 10

[Chris Waterson]

We were adding an extra template builder in the case that a first-ply overlay
node had a 'datasources=' attribute. Modify ResumeWalk() to only
CheckTemplateBuilder() when 2 or more deep (that is, the context stack is >2)
if we're in an overlay.

Comment 11

[esther]

Using win32 build dated 1999120816m12 and linux build 1999120808m12 this is
fixed.  Mac build 1999120808m12 still has the problem.  Will wait for the 12/9
mac build to retest on that platform.

Comment 12

[fenella]

Win32 (1999-12-09-10 M12)
Linux Redhat 6.0 (1999-12-09-10 M12)
This problem is fixed.
Mac build not available yet.

Comment 13

[esther]

Mac build 1999120910m12 ok too, verified