Closed Bug 198137 Opened 17 years ago Closed 11 years ago
Rename an address book and other areas of the product are not updated
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.
Assignee: racham → sspitzer
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.
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.
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 on attachment 181625 [details] [diff] [review] Patch to fix (checked in) a=asa
Attachment #181625 - Flags: approval1.8b2? → approval1.8b2+
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
QA Contact: nbaca → technutz
Resolution: --- → FIXED
Post-landing nit: it's is contractive; you want possessive "its"
(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)
Component: Address Book → MailNews: Address Book
Product: Mozilla Application Suite → Core
*** Bug 278674 has been marked as a duplicate of this bug. ***
*** 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
QA Contact: stephen.donner → addressbook
I am unable to rename an address book at all in TB 126.96.36.199
(In reply to comment #14) > I am unable to rename an address book at all in TB 188.8.131.52 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.
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.
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
Closed: 15 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.