Rename an address book and other areas of the product are not updated

RESOLVED FIXED

Status

MailNews Core
Address Book
RESOLVED FIXED
15 years ago
9 years ago

People

(Reporter: Ninoschka Baca, Unassigned)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
Trunk build 2003-03-13: Mac 10.1.5
Trunk build 2003-03-18: WinMe

Overview: Rename an address book and a variety of other areas are not updated
until the address book window is closed. 

Steps to reproduce:
1. Rename an address book and keep the address book window open
2. Now try opening other areas from the address book window:
a. Open the Search Addresses dialog, click on the "Search in" drop down
b. Select Edit|Preferences, Mail & Newsgroups, Addressing, click on the dropdown
menu for "Add email addresses to my".
c. Select the Compose button, select the Address button, click on the "Look in"
drop down menu
d. With the address book window still open, go to the thread pane, select the
Views drop down, select Customize, select New, then choose 'Sender" 'is in my
address book' and then select the third drop down menu to see the newly renamed
address book.

Actual Results:
2a. Still references the old name
2b. Still references the old name
2c. Still references the old name
2d. Still refernces the old name

After the address book window is closed then 2a, 2b, 2c and 2d reference the new
address book name. Atleast it does not require a restart.

Expected Results: The renamed address book name should appear in all areas of
the product immediately without requiring the address book window to be closed.
mass re-assign.
Assignee: racham → sspitzer
Product: Browser → Seamonkey
I've started looking into this. This next bit is just a note as to what is
possibly happening.

We seem to be at least attempting to update the RDF resource that supplies the
popup menus when we rename an address book, however the first time we do it, we
get this assertion (for each menu that has previously been shown, I think).

###!!! ASSERTION: expected a XUL document: 'xuldoc', file
/opt/mozmaster/mozilla/content/xul/templates/src/nsXULContentBuilder.cpp, line 1447
Break: at file
/opt/mozmaster/mozilla/content/xul/templates/src/nsXULContentBuilder.cpp, line 1447

It looks like the code in nsAbRDFDataSource::NotifyObservers is either written
incorrectly or something supplied to it is wrong. I'll investigate this further
as I get time.
Assignee: sspitzer → bugzilla
Further investigations:

1) Startup browser and bring up address book sidebar, select a non PAB or CAB
address book.
2) Bring up address book, and then the new card dialog, note state of popup
address book select menus.
3) exit new card dialog
4) rename the book that is selected in the sidebar (via the address book
window). Note the sidebar updating it's menu
5) bring up new card dialog, realise address book select menus haven't updated.
Created attachment 181625 [details] [diff] [review]
Patch to fix (checked in)

After talking with Enn on IRC it became clear that we're not actually telling
nsIAbDirectory about the change of name, so the menu lists were not being
updated because of that. This patch tells the nsIAbDirectory of the name change
in the same place as we update the prefs for the directory.

The only thing this doesn't achieve is updating the displayed value if the menu
is displayed when we rename it. Enn seemed to think this was a known bug with
rdf & xul, so I'd like to get this in and fixed as it is as there doesn't
appear to be an easy way around it.

The xul assertion is covered in bug 289422.
Attachment #181625 - Flags: superreview?(bienvenu)
Attachment #181625 - Flags: review?(bienvenu)
Status: NEW → ASSIGNED

Updated

13 years ago
Attachment #181625 - Flags: superreview?(bienvenu)
Attachment #181625 - Flags: superreview+
Attachment #181625 - Flags: review?(bienvenu)
Attachment #181625 - Flags: review+
Comment on attachment 181625 [details] [diff] [review]
Patch to fix (checked in)

Requesting approval for checkin, this is a long standing bug in address book,
however the fix is simple and should be low risk.
Attachment #181625 - Flags: approval1.8b2?

Comment 6

13 years ago
Comment on attachment 181625 [details] [diff] [review]
Patch to fix (checked in)

a=asa
Attachment #181625 - Flags: approval1.8b2? → approval1.8b2+
checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
QA Contact: nbaca → technutz
Resolution: --- → FIXED
Post-landing nit:

it's is contractive; you want possessive "its"

Comment 9

13 years ago
(In reply to comment #4)
>The only thing this doesn't achieve is updating the displayed value if the menu
>is displayed when we rename it.
Doesn't LoadPreviouslySelectedAB() take care of that? Maybe it needs to be moved
into common JS and called from other menulists.
Neil is right, by hooking up LoadPreviouslySelectedAB in the right places we
should be able to geth the UI updating at the same time as the rename. The first
patch is still valid though.

Reopening for extra ui fix.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: Backend fix some UI upgrades required.
Attachment #181625 - Attachment description: Patch to fix → Patch to fix (checked in)
Status: REOPENED → ASSIGNED
Blocks: 128342
Blocks: 128340
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
*** Bug 278674 has been marked as a duplicate of this bug. ***
Blocks: 135243
*** Bug 130741 has been marked as a duplicate of this bug. ***
*** Bug 291879 has been marked as a duplicate of this bug. ***
Assignee: bugzilla → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
QA Contact: stephen.donner → addressbook

Comment 14

11 years ago
I am unable to rename an address book at all in TB 1.5.0.8
(In reply to comment #14)
> I am unable to rename an address book at all in TB 1.5.0.8

You are not able to rename the Personal or Collected address books in TB at all (I think there's other bugs on this). Address books you create yourself may be renamed.

Comment 16

11 years ago
2a WFM both SM and TB trunk. No idea what fixed it.  Maybe it's all gone?

bug 135243 also seems to be gone.
bug 128342 still seen though.
didn't test bug 128340.
(Assignee)

Updated

10 years ago
Product: Core → MailNews Core
Depends on: 408613, 449260
Keywords: helpwanted
Whiteboard: Backend fix some UI upgrades required. → Bug 449260 should fix most of this, bug 408613 the rest
Depends on: 451381
This bug has been fixed by the patches on bug 408613, bug 449260 and bug 451381.
Whiteboard: Bug 449260 should fix most of this, bug 408613 the rest
Status: NEW → RESOLVED
Last Resolved: 13 years ago9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.