Closed Bug 1716858 Opened 3 years ago Closed 3 years ago

LDAP address books fail to return cards to browser.contacts.quickSearch

Categories

(Thunderbird :: Address Book, defect)

defect

Tracking

(thunderbird_esr78 wontfix)

RESOLVED FIXED
91 Branch
Tracking Status
thunderbird_esr78 --- wontfix

People

(Reporter: standard8, Assigned: darktrojan)

References

Details

Attachments

(2 files)

After some reports of issues from users, I was trying out LDAP contact search on 90.0b1 - when a card is found, the error console shows:

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIAbCard.UID] ext-addressBook.js:564

Stepping through I sometimes got a slightly different result, so I wonder if the UID is being allocated later which is why it fails.

The search still seems to succeed in this case.

The code is doing: card = await browser.contacts.quickSearch(email);

Flags: needinfo?(remotenonsense)
Regressed by: ldap-js

This is not regressed by js-ldap, because it happens on 90.0b1. The error is from https://searchfox.org/comm-central/rev/6c2198602b5c9fca956173df16c8a948d653a213/mailnews/addrbook/src/nsAbCardProperty.cpp#341-343, because LDAP directory is read only.

With trunk, it fails at https://searchfox.org/comm-central/rev/6c2198602b5c9fca956173df16c8a948d653a213/mail/components/extensions/parent/ext-addressBook.js#153-154,158, because when online, LDAP directory returns empty array in childCards.

Why do we use findContactById again in onSearchFoundCard https://searchfox.org/comm-central/rev/6c2198602b5c9fca956173df16c8a948d653a213/mail/components/extensions/parent/ext-addressBook.js#599. How should we fix it?

Flags: needinfo?(remotenonsense) → needinfo?(geoff)
No longer regressed by: ldap-js

Oh you're right, it can't be JS LDAP in 90.0b1. Excuse me, I'm only half-awake today. I think I know how to make this work.

Assignee: nobody → geoff
Status: NEW → ASSIGNED
Flags: needinfo?(geoff)

Just return NS_OK instead of saving. The card object will have this UID until it's destroyed, but getting the same card will have a different UID next time. I think this situation is only for LDAP anyway, so that doesn't matter at all.

I'm not sure why we even attempt to get the directory and save the UID, but I'm leaving it behind in case there are unintended consequences.

There's no need to find this object in the cache, just create a new one.

Depends on D118119

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/2c42926089dd
Don't throw an error when assigning a UID to a card in a read-only directory. r=mkmelin
https://hg.mozilla.org/comm-central/rev/68553b0e3d41
In contacts.quickSearch, simplify getting the returned object. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 91 Branch
Component: Add-Ons: Extensions API → Address Book
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: