434014 - Deleting a card from a mailing list properties window and the list selected in the main window doesn't update the display.

Status: RESOLVED WORKSFORME

(MailNews Core :: Address Book, defect)

Description

[Mark Banner (:standard8)]

This is the remaining problem after the landing of bug 406921:

Delete card from mailing list using properties window with mailing
list selected - doesn't update the display.

As per bug 406921 comment 9:

In case 14), there is no delete notification generated since the
'nsAddrDatabase::AddListAttributeColumnsToRow' does not check for deleted cards
in the mailing list. It seems the addresses are not actually deleted from the
'listRow'. Only the total number of addresses is set by 'SetListAddressTotal()'

I'd expect us to be able to do something with this after the interface re-factoring. as that should make list management easier.

Comment 2

[Thomas D. (:thomas8)]

The main-AB-window list of contacts contained in a Mailing List almost *never* updates correctly for any changes done in the Mailing list properties window. Instead, it creates all sorts of temporary ghost artefacts which in turn cause more user confusion, dataloss, and lots of extremely complex bug reports. Grrrrrrrr!

Bug 628035, Bug 434014, Bug 534564, Bug 715694, ...

About the wrong relationship between cards and lists:
Meta Bug 757736

Comment 3

[Thomas D. (:thomas8)]

Mark Banner (reporter), given that "New AB" has rightly been postponed and we never know when it will arrive, any chance that TB devs can fix this technical contact list update problem which is causing all sorts of bad UX including dataloss? For overview of resulting problems, see Meta bug 758969 (1) below.

(In reply to Thomas D. from comment #2)
> The main-AB-window list of contacts contained in a Mailing List almost
> *never* updates correctly for any changes done in the Mailing list
> properties window. Instead, it creates all sorts of temporary ghost
> artefacts which in turn cause more user confusion, dataloss, and lots of
> extremely complex bug reports. Grrrrrrrr!

I filed a Meta Bug to collect reports caused by underlying problem of this bug 434014:

Bug 758969 (1) - [Meta] Mailing Lists: Bugs caused by problem: Contacts list pane of contained contacts not updated/refreshed (artefacts, duplicate entries, apparent and real dataloss of cards, display names etc.)

(1) https://bugzilla.mozilla.org/show_bug.cgi?id=758969

Comment 4

[Thomas D. (:thomas8)]

Bug 1061648 tried to fix this, but caused regression of Bug 1106783.
I understand Bug 1061648 attachment 8485153 [details] [diff] [review] deliberately skipped the notification/observers mechanism mentioned here in comment 0, as described in plan for the patch there:

(In reply to Stephen Schaub from Bug 1061648 comment #1)
> There are really two separate issues involved in the bug: 
> 1. When the user edits a mailing list, removes one or more entries, and
> clicks OK, an exception is thrown in GetListValue() (abMailListDialog.js)
> due to inadequate code checks to handle this case. There's a straightforward
> fix for this (decrement the oldTotal variable after removing an item from
> the list). 
> 
> 2. After #1 is fixed, the list display doesn't refresh properly: extra items
> appear at the end of the list. The user has to manually refresh the display
> by selecting a separate list or address book, then selecting the list again.
> I think this happens because the nsAddrDatabase::EditMailList processing
> uses the observer mechanism to notify listeners (including nsAbView) about
> changes to the mailing list, but the current implementation does not
> correctly handle the case when the resulting list is shorter than the
> original. 
> 
> My thought about #2 is that there is probably no reasonable way to use the
> existing observer mechanism to properly refresh the list when the changed
> list is shorter than the original. I suggest that a better approach to
> updating mail list display after an edit is to force a complete refresh of
> the nsAbView. I think this would also neatly solve some other issues related
> to refresh of the display after a mailing list edit.

Comment 5

[Stephen Schaub]

> I understand Bug 1061648 attachment 8485153 [details] [diff] [review] [diff] [review] deliberately skipped the 
> notification/observers mechanism mentioned here in comment 0, as described in plan for the patch there:

To clarify: The patch for Bug 1061648 does *not* skip the notification/observers mechanism. It simply adds a refresh of the display after the usual notifications are fired, to deal with the inadequacy of the notification mechanism.

Comment 6

[Thomas D. (:thomas8)]

This wfm on 102.4.2 (64-bit), Win10.