1318405 - Address book search / filter reset without clearing search field after deleting contact

Status: RESOLVED WORKSFORME

(Thunderbird :: Address Book, defect)

Description

[Jonathan Kamens]

(Pretty sure this is still a bug on the trunk, but reporting it against 45 because that's where I verified it today.)

1. Open the address book.

2. Do a search to limit which contacts are displayed.

3. Click on one of them, click the Delete button to delete it, and confirm the delete.

4. Observe that your search term remains in the search box, but the contact list has reset to everyone rather than to the contacts that match the search.

The ideal behavior here would be for the search to persist properly after the delete, i.e., the contact list would continue to list only the contacts matching the search. Less ideal, but better than current behavior, would be for the search box to be cleared after a delete. The current behavior, where the search box remains filled in but is no longer being applied, is clearly wrong.

Comment 1

[:aceman]

I can't reproduce this, neither in 45 nor trunk.

Comment 2

[Jonathan Kamens]

I just reproduced this in safe mode with daily (2016-11-18).

Do you have multiple address books? It is possible that this issue only occurs when there are multiple address books and you're searching / filtering in "All Address Books" rather than just one of them.

Indeed, I just tested while a single address book rather than "All Address Books" is selected, and it doesn't happen then.

Comment 3

[Jorg K (CEST = GMT+2)]

I can reproduce this in Daily. Multiple address books present. Click "All Address Books", search, delete. Result: Contact deleted, all contacts showing, but search term not cleared.

Comment 4

[Massimiliano Caniparoli]

I can reproduce it on 50.0b3 as well.

Comment 5

[:aceman]

We take different code paths depending on whether the All ABs item is selected or not.

I'd try removing the SetAbView call at
https://dxr.mozilla.org/comm-central/rev/4eeb3f3d3ec60193f6c908170a202c20b649f390/mail/components/addrbook/content/abCommon.js#380 . It looses the seachURI string and shows full "All addressbooks" item without any search applied (compare with https://dxr.mozilla.org/comm-central/rev/4eeb3f3d3ec60193f6c908170a202c20b649f390/mail/components/addrbook/content/addressbook.js#540).

Thomas, can you try that?

Comment 6

[Thomas D. (:thomas8)]

(In reply to :aceman from comment #5)
> We take different code paths depending on whether the All ABs item is
> selected or not.
> 
> I'd try removing the SetAbView call [...]
> Thomas, can you try that?

Sure. Just removing the call keeps the searchword and search applied, but unfortunately the deleted entry doesn't disappear from view (although it looses the addressbook attribute, interesting...)

So after deleting from All-AB, we'd have to update the search, similar to that other spot which you referenced.

Comment 7

[Thomas D. (:thomas8)]

Note that we actually want to select the next item after deleting, or, of there's no next item, the previous item (i.e. the last item). Or nothing if it was the only item.

Surprisingly, just using the onEnterInSearchBar() routine will select another AB after deleting.

Comment 8

[greg]

Behavior present on 52.6.0.

Comment 11

[Patrik Ragnarsson]

I just experienced this on 66.0b3 (64-bit).

The ideal behavior here would be for the search to persist properly after the delete, i.e., the contact list would continue to list only the contacts matching the search.

I expected this to be the case.

Comment 12

[Massimiliano Caniparoli]

I just read from TB 79 Beta release notes that this should be solved now, and I tried once. Could you please test it as well? :)

Comment 13

[Thomas D. (:thomas8)]

(In reply to Massimiliano Caniparoli from comment #12)

I just read from TB 79 Beta release notes that this should be solved now, and I tried once. Could you please test it as well? :)

No, that's Bug 1644084 which was fixed, not this one. As you can see, this bug 1318405 is still NEW, i.e. not yet fixed.
But in fact, this bug is also worksforme (maybe fixed by Bug 1644084) on TB 79.0b1 (32-bit), Win10.

Comment 14

[Massimiliano Caniparoli]

I agree :) It didn't work before, but probably #1644084 also solved this one