Closed Bug 1223951 Opened 10 years ago Closed 1 year ago

Search results inconsistently counted; To/From wrong

Categories

(Thunderbird :: Search, defect)

38 Branch
Unspecified
Windows 7
defect

Tracking

(thunderbird_esr115 wontfix, thunderbird_esr128 wontfix, thunderbird138 wontfix, thunderbird139 wontfix, thunderbird140 fixed, thunderbird141 fixed)

RESOLVED FIXED
141 Branch
Tracking Status
thunderbird_esr115 --- wontfix
thunderbird_esr128 --- wontfix
thunderbird138 --- wontfix
thunderbird139 --- wontfix
thunderbird140 --- fixed
thunderbird141 --- fixed

People

(Reporter: firstpeterfourten, Assigned: welpy-cw)

References

Details

Attachments

(5 files, 1 obsolete file)

Attached image Search results page
I am observing some strange behavior with search and am not sure if this is all one bug with one root cause, multiple bugs with interrelated root causes, or multiple unrelated bugs. If there are multiple bugs, they can be split out. Attached are a couple screenshots taken in a just-updated TB 38.3.0 (but the issue was observed before that too) in Safe Mode, to determine that the bug is in the current base TB. Green annotations remove personal data and red ones point out unexpected behavior. The setup was that I did a global search that returned one result. In the search results window, my email address was listed twice in the “to” field (instead of once) and the “from” field was incorrect, apparently pulling a string from the From field of another message in the same folder (or possibly from elsewhere). In the list of search refinements on the left, both my e-mail address and the (incorrect) sender were listed, with the number 2, apparently indicating that two messages in the one-item search result set involved each party. Adding a “Must involve” constraint for either of the People listed doesn’t change the search result set (i.e. no second message appears). I would expect 1s in place of those 2s. From clicking Open Email As List (before/without any search constraints), I get the second screenshot listing one message, with content that includes the snippet on the search results page. Here you can see that the organization this message is From is different than the organization listed in the search results page. In this view, you can also see that it’s sent to me at my e-mail address just once, instead of the double listing on the search results page. This matches the single instance of my address shown in the To: header when viewing source.
Attached image "Open email as list" page (obsolete) —
Attachment #8686237 - Attachment is obsolete: true
OS: Unspecified → Windows 7
Attached image Thunderbird001.png
I've been seeing the "incorrect from" address behavior for awhile now. It consistently affects the "local" address, both "From" and "To" of any email in the search results list. The remote correspondent's address is always OK. In my case the address substituted is consistently another address used on a different IMAP login in the same Thunderbird profile. I've attached a screenshot from version 45.1.0 showing the problem.
Do these issues go away if you create a new profile?
(In reply to Wayne Mery (:wsmwk) from comment #4) > Do these issues go away if you create a new profile?
Flags: needinfo?(firstpeterfourten)
Whiteboard: [closeme 2018-10-05]
(In reply to Wayne Mery (:wsmwk) from comment #4) > Do these issues go away if you create a new profile? I don't know. With so many long-unresolved bugs and philosophy change that knock out the user control and customizability that attracted me to TB in the first place (e.g. removing informed-consent control of add-ons that serve core functionality for a use case getting automatically and irrevocably disabled after a forced update), I gave up on TB, at least for now (and the last/next several months at least). I invested a fair bit of time getting the issue boiled down to a specific test, taking screenshots and annotating them, describing the issue concisely and in a way that I hoped other developers would be able to pick up and run with, all in vain. I would hope this issue isn't going to be closed just because the original reporter can't respond to a request for additional testing and information (implying that nobody else can do that either), but I wouldn't be surprised especially due to the 'closeme' tag. I would then not be surprised to see future dupes get closed on the grounds that nobody fixed this one, and the absence of volunteers doing anything specific in a no-obligation community somehow implies the bug report should be ruled out. Here's my flag in the ground commenting that as the reporter of this bug, I don't support that happening and would rather see the bug open until it can be fixed, maybe with some collaborative effort on testing different conditions to narrow down on the cause.
Flags: needinfo?(firstpeterfourten)
Whiteboard: [closeme 2018-10-05]
Depends on: 1526985
Severity: normal → S3

The first time GloDa encounters a sender or recipient without an email address, it creates a contact with an empty email address as the key and the provided name. This contact will be returned for any correspondent without an email address, so the wrong name will mostly be displayed.

This patch resolves the issue by creating a separate contact for any name without an email address.

Assignee: nobody → h.w.forms
Status: NEW → ASSIGNED
Blocks: 1831475

How to test:

  1. Search for a unique message and note the count of the recipients in the faceted search view.
  2. Disable "Include messages in this folder in Global Search results" for the folder containing that message.
  3. Enable it again and repeat step 1.
Target Milestone: --- → 141 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/6d3feb34b2e7
Fix the way GloDa handles contacts without an email address. r=john.bieling

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/26922bacc3b6
Do not duplicate correspondents when re-indexing a gloda message. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

Comment on attachment 9489614 [details]
Bug 1223951 - Fix the way GloDa handles contacts without an email address. r=#thunderbird-reviewers

Beta/Release Uplift Approval Request

  • User impact if declined/Reason for urgency: Messages from authors without an actual email address are not indexed by Gloda at all.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Nightly?: Yes
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simple change that's covered by automatic tests.
  • String changes made/needed: None.
  • Is Android affected?: No
Attachment #9489614 - Flags: approval-mozilla-beta?

Comment on attachment 9489614 [details]
Bug 1223951 - Fix the way GloDa handles contacts without an email address. r=#thunderbird-reviewers

Uplift Approval Request

  • Please state case for uplift consideration and ensure bug severity is set:
  • User impact if declined: Messages from authors without an actual email address are not indexed at all by Gloda.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Daily?: Yes
  • Has the fix been verified in Beta?: No
  • Needs manual test from QA?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simple fix covered by automated tests.
  • String changes made/needed: None
Attachment #9489614 - Flags: approval-mozilla-beta? → approval-comm-beta?

Comment on attachment 9490112 [details]
Bug 1223951 - Do not duplicate correspondents when re-indexing a gloda message. r=#thunderbird-reviewers

Uplift Approval Request

  • Please state case for uplift consideration and ensure bug severity is set: Every time a message is re-indexed by Gloda, its correspondents are duplicated.
  • User impact if declined: Several duplicated correspondents may be displayed for an email in faceted search.
  • Is this code covered by automated tests?: Yes
  • Has the fix been verified in Daily?: Yes
  • Has the fix been verified in Beta?: No
  • Needs manual test from QA?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): Simple fix covered by automated tests.
  • String changes made/needed: None.
Attachment #9490112 - Flags: approval-comm-beta?

Comment on attachment 9489614 [details]
Bug 1223951 - Fix the way GloDa handles contacts without an email address. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta
Dovetails to bug 1831475

Attachment #9489614 - Flags: approval-comm-beta? → approval-comm-beta+

Comment on attachment 9490112 [details]
Bug 1223951 - Do not duplicate correspondents when re-indexing a gloda message. r=#thunderbird-reviewers

[Triage Comment]
Approved for beta
Dovetails to bug 1831475

Attachment #9490112 - Flags: approval-comm-beta? → approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: